"mdev -s" fails to create /dev entries

[Denys Vlasenko]

On Saturday 12 July 2008 10:06, Holland, John wrote:
> >> That is when you stay within /sys/class or /sys/block. Operating on the
> >> whole of /sys and following non-symlinks only will and does find all dev
> >> files reliably (don't know about the above mentioned loop devices).
> >
> >Ok, I'll bite.  If you look under /sys/devices for "dev" nodes, how do you 
> >tell if you've got a char device or a block device?  (I'd really like to 
> >know.)
> 
> As Vladimir previously posted they too have '/block/' somewhere in their
> non-symlink path (i.e. loop devices on 2.6.25). This must be thoroughly
> tested.

You convinced me that testing for "/block/" in the name
will be more reliable - kernel people are unlikely to have that
in char device name. I hope.

> >(This is glossing over the fact that searching through an arbitrarily 
> >large /sys tree could be very slow on certain systems, and a lot of embedded 
> >stuff is using 100 mhz processors and such, and prefer mdev to udev for the 
> >_speed_ as much as for the memory savings.)
> 
> You're right... However, those tiny systems normally do not have the number
> of devices/modules as the others. If you wish, we could leave dirAction and
> redefine it not to walk through certain directories ('/modules/').
> 
> For me, speed is secondary. I'd prefer that mdev works as intended on many
> kernels, w/o having to worry if mdev will work on some forthcoming kernel.

You cannot neglect other user's needs like that.

Let's implement strstr("/block/") thing but restrict the scan to /sys/block
and /sys/class for now.

BTW: there is a speedup opportunity in mdev -s: we parse config file repeatedly
(which includes compiling regexp) for each device scanned!
Volunteers to fix that?
--
vda