Messages in this thread | | | From | Rusty Russell <> | Subject | Re: [RFC PATCH] Allow optional module parameters | Date | Fri, 15 Mar 2013 15:33:32 +1030 |
| |
Andy Lutomirski <luto@amacapital.net> writes: > Current parameter behavior is odd. Boot parameters that have values > and don't match anything become environment variables, with no > warning. Boot parameters without values that don't match anything > go into argv_init. Everything goes into /proc/cmdline. > > The init_module and finit_module syscalls, however, are strict: > parameters that don't match result in -ENOENT. > > kmod (and hence modprobe), when loading a module called foo, look in > /proc/cmdline for foo.x or foo.x=y, strip off the foo., and pass the > rest to init_module. > > The upshot is that booting with module.nonexistent_parameter=1 is > okay if module is built in or missing entirely but prevents module > from loading if it's an actual module. Similarly, option module > nonexistent_parameter=1 in /etc/modprobe.d prevents the module from > loading the parameter goes away. This means that removing module > parameters unnecessarily breaks things.
Err, yes. Don't remove module parameters, they're part of the API. Do you have a particular example?
> With this patch, module parameters can be made explicitly optional. > This approach is IMO silly, but it's unlikely to break anything, > since I doubt that anyone needs init parameters or init environment > variables that end in a tilde.
It's silly for the removal problem: that should be handled in the kernel. How would the poor user know that the option is going away? So how about we add a module_param_obsolete(name) macro?
If a parameter were introduced, and the user wanted to specify it *if* it was supported, that might justify this approach rather than using complex install commands. But I don't believe that's common, is it?
Thanks, Rusty.
| |