Marco d'Itri wrote: > If the problem is only passing parameters from the kernel command line > then you can solve this with a script which parses it and writes the > parameters to a file in /etc/modprobe.d/.
Part of the problem with doing it that way is that it requires either keeping a list of supported kernel parameters and the modules they go to (possibly extracted from the module data), or just passing all kernel parameters into each module. The first seems hard, the second might work for the installer but is not suitable for setting in /etc/modprobe.d/ in the installed system. So with discover we took the third route of allowing the user to enter in debconf module parameters for selected modules which discover identified, before they are loaded. This has never been ideal, both because it's a bad UI and because even with discover there are plenty of modules that are loaded earlier that the user cannot specify kernel parameters for. Another way to do this might be to tag parameters on the command line with the module they apply to. Matthew Wilcox suggests in this bug report that libata.atapi_enabled=1 will send that parameter to the libata driver if it's compiled in; I wasn't aware of this syntax before. Is it documented somewhere (kernel source file is fine ;-) and does it work for other module parameters? Seems we could just parse that if so. (Hmm, we also currently only write those entered module parameters to the installed system's /etc/modutils/, not to its /etc/modprobe.d/, wonder if we should change that too..) > If there is a good reason to have udev load the modules for different > classes of devices at different times then this can be arranged too, > look at /sbin/udevsynthesize for the general idea. If we could somehow use this to a) delay udev from loading modules for eg, disk and cd drives at boot b) later get udev to give us a list of the modules it wants to load so we could prompt for parameters and load them Then yes, that might work. I can sort of see how to do a. -- make udevsynthesize avoid doing anything with block devices. Doing b. (without essentially rewriting udev) would involve messing with udev's rules that run modprobe and replacing it with something to add the module to a list that we could examine later. Seems likely to get ugly fast. -- see shy jo
signature.asc
Description: Digital signature
