Hi all, Since my last modprobe patch, I've been figuring out why various other things go wrong, and why bb modprobe is still so slow on my old box (0.24s vs module-init-tools 0.05s).
There seems to be two major problems: 1. bb modprobe does not support multiple aliases: E.g. I'm using ipsec with aes and the current kernel aliases files has: alias aes padlock_aes alias aes geode_aes alias aes aes_generic alias aes aes_i586 And when kernel requests for module "aes", modprobe just ends up trying padlock_aes (which won't load on most of my boxes) and errors out. module-init-tools tries all the aliased modules in order. Actually, preferable would be if it tried the _generic variant last. 2. memory hungyness causes slowness I tracked down that the slowness is caused because bb modprobe loads all config files including aliases (there is *a lot* of them) to memory. The seems to slow it down since additional brk() kernel calls needs to be made too. And of course using lots of heap is bad for memory limited boxes. module-init-tools just takes the module name, and parses the files and loads only the related stuff (e.g. discards unneeded aliases, but keeps all options statements as modprobe can load additional modules; this can be done since module-init-tools does not allow dependency to be an alias). Also module-init-tools smartly loads only required files; e.g. .symbols file is not parsed unless the requested module starts with "symbol:". Etc. Btw. module-init-tools also accept "-a" to load multiple modules at once, it just re-reads the config files for each requested module. Now, I'm writing to ask if I was to make bb modprobe more or less module-init-tools alike in these aspects (which would mean pretty big changes) would it be accepted in? Assuming the size difference is not too big (the new code might end up being smaller since it would require less code for memallocs etc.). I can test it well on a 2.6 box. But it might also mean no-support for 2.4 unless someone can test it (but I think the current support for 2.4 is untested too). Cheers, Timo _______________________________________________ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
