modprobe/insmod woes...

Rob Landley rob at landley.net
Sun Jan 8 20:33:40 UTC 2006


On Sunday 08 January 2006 04:15, Yann E. MORIN wrote:
> On Saturday 07 January 2006 065, Jonathan Lyster wrote:
> > Here's the trouble: insmod doesn't support the -s switch. So the solution
> > is either to tweak modprobe so it doesn't pass the switch to insmod, or
> > tweak insmod to support -s.
>
> As Rob says, insmod should now ignore -s. Try current svn.
>
> Now, we should wonder if we should pass -s to insmod, and ignore it there,
> or simply throw away the -s straight in modprobe.
>
> The answer is trivial: are we sure it will be insmod from busybox? No, of
> course not, it might be from modutils or modules-init-tools.

In which case why the heck are they using busybox for the other half of the 
transaction?

General rule of thumb of mine is if you're going to use a tightly integrated 
package like module-init-tools, you should use it for everything it supports.  
Busybox probably shouldn't be concerned _that_ much about cherry-picking, 
because we can't do anything about version skew anyway.

Now the Linux kernel is a package we have to worry about interfacing with, so 
let's see what that does.  The 2.6 kernel triggers dynamic module loading by 
calling request_module() all over the place, and that's implemented in 
kernel/kmod.c, which has the following setup under 2.6.15:

        char *argv[] = { modprobe_path, "-q", "--", module_name, NULL };
        static char *envp[] = { "HOME=/",
                                "TERM=linux",
                                "PATH=/sbin:/usr/sbin:/bin:/usr/bin",
                                NULL };

(Yes, you can now trivially execv() from the kernel!  Woot!)

So anyway, as long as our modprobe understands "-q -- modname" we're good, and 
as long as our insmod understands what our modprobe calls it with, we're 
good.

> So our 
> modprobe must pass the -s switch onto insmod. And our insmod shall simply
> ignore it, which it does now (or better implement logging via syslog :-) ).

Implementing logging via syslog in the future sounds cool.  Should that be a 
config option?  (If so, passing the -s should be controlled by the same 
config option.)

Now possibly a good reason to ignore -s is that existing _scripts_ might have 
that in there.  But then again if busybox is ignoring it instead of doing the 
logging the script asks for, I lean towards erroring out loudly so they can 
find and fix their script as better than silently not doing what they asked 
us to.  (They shouldn't ask for logging if they don't want logging.)

> Regards,
> Yann E. MORIN.

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.



More information about the busybox mailing list