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 _______________________________________________ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox