You all are right! I already proposed to create an optional FEATURE_KERNEL_SOURCES_PATH var in BB config. Then those who prefer compatibility would feed it with kernel sources path, and mdev.c could choose appropriate workarounds. Those who prefer size/speed would ignore it and mdev.c could behave just as it does now.
-- Vladimir 2008/7/12, Holland, John <[EMAIL PROTECTED]>: > >>> 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. > >>(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. > > ___________________________________________ > > Cellent Finance Solutions AG > > Firmensitz: Calwer Straße 33, 70173 Stuttgart > Registergericht: Amtsgericht Stuttgart, HRB 720743 > Vorstand: Thomas Wild > Vorsitzender des Aufsichtsrats: Rudolf Zipf > _______________________________________________ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox