Using busybox as kmod (module-init-tools) replacement

[Mike Looijmans <mike.looijmans@topic.nl>]

Busybox 1.23 can also provide the "modprobe" and related commands like 
"lsmod". This makes it possible to remove "kmod" from an image and replace it 
with busybox's smaller implementation. I tried that on some settop box images 
and that works just fine, for example USB wifi drivers get properly loaded 
into memory when plugged in.

I ended up with some rather ugly constructs. Apparently it is 
"module-init-tools" that gets installed in one of the core packagegroups, so 
these things appear logical to do then:

PREFERRED_PROVIDER_module-init-tools = "busybox"

These lines in the busybox recipe (to be made conditional, e.g. by parsing the 
config):

PROVIDES += "module-init-tools"
RPROVIDES_${PN} += "module-init-tools kmod"

The "kmod" is in there because some recipes just (R)DEPEND on "kmod", while 
they actually only need a modprobe command.

Reading the kmod recipe, it appears that "module-init-tools" used to be 
something that actually existed but has been obsolete for quite a while. Maybe 
it would be better to introduce a "virtual/kernel-module-manager" or so?

Looks like some cleanup may be in order here - "udev" also has a hard 
dependency on "kmod", and building both kmod and busybox now leads to 
conflicts. So that would prohibit anyone using udev in combination with this 
busybox configuration.

Any comments, suggestions on this? (Or is replacing kmod a stupid idea to 
begin with)


Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijmans@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail