Ludovic Courtès writes: > I wonder if we could reuse the ‘kernel-loadable-modules’ field > for this > purpose instead of introducing a new field. We’d need to pass > it to the > initrd procedures and have them search in there in addition to > the > kernel package, pretty much like this patch already does > actually. This sounds like it could be made to work as you suggest. My feeling is that the two contexts are slightly different, though, as the Linux modules are a superset of the initrd modules, so I’d prefer not to mix them as it might be confusing to people who are used to other Linux distros where the initrd modules are called out separately. I admit I’m probably being silly here, and don’t have any serious objection in principle. > Nitpick: the GNU convention is to use “path” to denote “search > paths”, > and other “file”, “file name”, or similar. In this case, that’d > be > “kernel module” or “Linux module”. I struggled with this a fair amount, actually. What these file-likes actually represent is an element of a search path, even if they come in the odd form of a file-like object, which is why I used ‘path’. ‘file’ seems wrong, as it implies (to me) that it’s the ‘initrd-extra-module-files’ option itself that would include the module, rather than the ‘initrd-modules’ option. Of course, all this goes away if we just reuse ‘kernel-loadable-modules’ as an additional input, rather than adding another option, so that’s a distinct mark in favor of doing that. When I get some time (hopefully soon!) I’ll try to thread ‘kernel-loadable-modules’ through instead and see how far I can get with that approach. Do you think the documentation for it will need to be updated to specify that it’s also used as a search path for initrd building? Or maybe the better option is to update the documentation for ‘initrd-modules’ to say that it uses ‘kernel-loadable-modules’ as input? -bjc