On Tue, May 10, 2011 at 3:08 PM, Thomas Bächler <thomas@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