TL;DR: the current busybox (or my code) seems to be broken on one or two systems out of thousands; crucial modules don't get loaded using hotplug + coldplug. Please give me a runtime option so I can give my users a boot-time option to try the new approach.
On Fri, Mar 13, 2015 at 02:04 PM, Guillermo Rodriguez Garcia said: > Perhaps my message is not getting across. What I am saying is > that I am not sure your suggestion is actually something others > would find useful. Other than the fact that you like it > yourself I don't see a lot of enthusiasm around about it. I've been following this thread on and off and I feel *very* enthusiastic about Harald Becker's approach. I kept silent because there was already so much posting and I figured everyone would finally get on board with Harald's suggestions. I admit I build my own busybox but I would *hate* to have to make this choice at build-time. I want to give my users a boot-time option ("failsafe" or something like that) to go back to the older, slower way. Or maybe make the older way the default and give them an option to use the new approach. Making it a build-time option is extremely hubristic; it assumes both the current code and the new code are perfect. I have a few users (out of many thousands) who have trouble loading modules they need using the conventional busybox tools. I enable hotplugging and then coldplug, loading everything from: /sys/devices -name modalias -exec cat '{}' + 2>/dev/null I've also used: find /sys/devices -name uevent -exec sed -n \ 's/^MODALIAS=//p' '{}' + 2>/dev/null \ But after filtering through "sort -u" the outputs of the find commands are identical. So I have a failsafe fallback that loads all modules from: /lib/modules/$(uname -r) The alias for the needed module shows up in those lists but they don't always get loaded. Oddly enough the crucial modules does *not* show up when I pipe that output through: | xargs modprobe -a -D But it shows up when I use the Debian modprobe. The crucial module does get loaded on my system when I use: | xargs modprobe -a This is a strange bug in "modprobe -a -D" but it does not explain the bug that causes failure to load certain modules via hotplug + coldplug. Maybe the bug is in my code; maybe the bug is in busybox. I don't know for sure. My guess is it is a glitch in the hotplugging. I have not heard back from the user who reported the problem. The next test would be to keep doing the cold-plugging and see if that fixes the problem. Last year I discovered and reported a bug in the small modprobe when it did not load certain modules during a coldplug. The bug was fixed but I have since moved to the large modprobe. I'm hoping that a more streamlined and orderly hotplug solution in busybox will fix the problem above so I don't have to ever resort to loading all modules. If Harald's solution is a runtime option then I could make it a boot-time option and test it on thousands of machines. ISTM this is the only sane approach. I also liked this suggestion from Natanael: On Fri, Mar 13, 2015 at 10:33 AM, Natanael Copa said: > While solving this, I would also like to find a way to load the > MODALIAS without forking. But I don't think this is the answer: > One option is to add modprobe -i which reads modaliases from > stdin with a timeout. Maybe that is a lower hanging fruit than > mdev -i? Since ISTM that can be handled with xargs (does that fork a lot?). ISTM there is a lot of forking in the find commands as illustrated above. I think we would need to use: modprobe --find-modalias /sys/devices where the user gets to define which directory is searched. There could also be a: modprobe --find-uevent /sys/devices where the grep/sed is built-in as well. OTOH, perhaps these would be a nightmare code-wise. I'd sure like to know if this approach is significantly faster or not. BTW: I try to time most things in my initrd init script to keep an eye on what slows things down so we can stay as speedy as possible. I use: cut -d" " -f22 /proc/self/stat to get the time in hundredths of a second since the kernel booted. But this itself and the associated arithmetic is not free time-wise. So I disable most of the timing when I'm not in debug mode. If there is a better/faster way to get the time to hundredths of a second or better, PLMK. A shell built-in would make me very happy. Perhaps this seems way OT but ISTM that precise timing is essential for comparing how fast things are when the overall time is only a second or two. If there is a better way to get the time, PLMK; otherwise I suggest people use the cut command above for timing how long things take. Peace, James _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox