Andy Lutomirski <l...@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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/