[arch-projects] [initscripts][udev][RFC] first step towards removing load-modules.sh

[Tom Gundersen]

On Tue, May 10, 2011 at 3:08 PM, Thomas Bächler <thomas at archlinux.org> wrote:
> Am 10.05.2011 15:02, schrieb Dave Reisner:
>> I'm going to argue that we should be going the install /bin/false route,
>> as it more accurately mimics what we currently do with load-modules.sh.
>> This does have the drawback that if a user really does in fact want to
>> install a given module, they need to run modprobe with -i. I don't
>> recall if load-modules.sh allows explicit installation of a "blacklisted"
>> module.
>
> 'blacklist' is fine. It usually only blacklists aliases of a module, but
> udev uses 'modprobe -b', which blacklists the module name as well - this
> is the behaviour I was trying to mimic with load-modules.sh.

I prefer blacklist, especially if it is what was intended with
load-modules.sh. However, I am ready to jump to `install /bin/false´
if things break in horrible ways.

>> As I mentioned to you on your GH pull request, I'm still a bit weary of
>> starting up a symlink farming business in /run. I would love to see
>> module-init-tools support for reading from /run/modprobe.d, but perhaps
>> that's a bit of an exotic request.

Not at all. It makes perfect sense to make modules-init-tools use the
same /run, /etc, /usr/lib hierarchy as everything else in systemd
does. I am sure upstream patches would be eagerly accepted (and I
would be the first one to simplify our implementation) ;-).

> If we could just have a statement like
>  include /run/modprobe.d/
> in a modprobe config file. At least nothing like this is documented.

That would certainly also work for our purposes. However, I think
there is a benefit in allowing packages to install their own
modprobe.conf files (as described below for modules-load.d). I guess
care must be taken as clashes are possible though, and this would only
be interesting if it is adopted upstream so packages can rely on it
across all distros.

>> semi-random aside: does anyone other than systemd support
>> /etc/modules-load.d?

Not to my knowledge. However, I got the impression that Upstart is
looking to implement the same standard config files as systemd is
doing, so I think there is great benefit in being compatible with
`everybody else´. Regardless of that, it is a neat idea. See below.

> What is that supposed to do?

I wanted to suggest this for the future (at the moment this
functionality is not hooked up in initscripts):

/etc/modules-load.d/*.conf are just newline separated lists of modules
to load at boot (so modules-load.d + modprobe.d can do the same as our
MODULES array).

Looking at the man pages this can be done much more nicely than what I
did in my patch (actually, it works the way Dave wanted modprobe.d to
work): <http://0pointer.de/public/systemd-man/modules-load.d.html>. I
will remove the modprobe.d stuff from my patch, as it is not hooked up
yet.

I will revisit this once the next release is out. A quick idea of what
I have in mind:

The benefit of modprobe.d compared with the MODULES array is that
packages can install lists of modules they need loaded in
/usr/lib/modules-load.d/ (rather than advice the user to add them to
their MODULES array).

How we should do this:

Generate /run/modules-load.d/rc.conf at boot based on the MODULES array.
The user can add their own lists of modules to
/etc/modules-load.d/*.conf and it will be the same as adding it to
rc.conf.
Packages can add lists of modules to /usr/lib/modules-load.d/*.conf.

Then we process all these sources in the same way as we do with the
MODULES array now, with the added benefit that it will be compatible
with other distros (and upstream packages/tools can rely on this also
on Arch).

Cheers,

Tom