[arch-dev-public] Module blacklisting

[Dan McGee]

On Fri, Feb 22, 2008 at 6:03 PM, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> On Fri, Feb 22, 2008 at 5:56 PM, eliott <eliott at cactuswax.net> wrote:
>  > On 2/22/08, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
>  >  > Ok, guys - honest question. Because udev is being a big pain in the
>  >  >  ass with the way we do module blacklisting, we might want to
>  >  >  reevaluate it.
>  >  >
>  >  >  Right now we support blacklisting of modules in rc.conf, in addition
>  >  >  to a kernel param disablemodules=x,y,z
>  >  >
>  >  >  Udev autoloading is controlled by MOD_AUTOLOAD and the load_modules
>  >  >  kernel param.
>  >  >
>  >  >  We *can* use modprobe based blacklisting here, but we lose the above
>  >  >  items. blacklisting will be controlled only by /etc/modprobe.conf (and
>  >  >  modprobe.d/*) and we lose the ability to shut it off via rc.conf.
>  >  >
>  >  >  What do we gain? Speed and simplicity. No extraneous scripts to handle
>  >  >  this stuff, and all that jazz.
>  >  >
>  >  >  This is how fast this script was when I originally wrote it:
>  >  >  http://img.phraktured.net/other/udev_modules_boot.png
>  >  >  Now it apparently takes 3 times as long due to all the added blacklisting cruft
>  >  >
>  >  >  What do we lose? Robustness.
>  >  >  See below for an explanation of the blacklist changes
>  >
>  >  I thin modprobe.conf would probably be 'cleaner' and 'closer to home'.
>  >  It would probably be a little less 'classic arch', as it moves things
>  >  away from rc.conf instead of into it. It might be the right thing to
>  >  do though..not sure.
>
>  That's about where I am right now. It feels cleaner, but begins moving
>  things out of rc.conf, which is un-Archy. I dunno, I'm hoping to hear
>  other people's opinions on this, as I'm holding off pushing out a udev
>  with start_udev still in it until we decide what to do here... anyone
>  have a strong opinion?

I like it in rc.conf. I've always loved the single point of config for
most startup things, and I know I see this as a great selling point of
Arch in our own forums and elsewhere. I'd really rather not move it
outside of there.

This is a point someone made earlier in the thread that I wanted to
address, and it went something like this:
"why don't we just do the blacklist variable stuff in the initscripts"

Aaron covered it most of the way, but I just wanted to make it clear
that every time you plug in a USB device or make any other hardware
chage, udev triggers. If I've added a blacklisted module since the
last time I booted (which may have been 50 days ago), then I want it
to not load, and any processing of udev-related stuff outside of the
udev framework would mean the module I added would not be blacklisted.

>  >  I do have one concern though. How would this effect mkinitcpio, and
>  >  excluding modules via grub at boot time (whether from an install cd or
>  >  from a real boot and with an initrd)?
>
>  That's harder. But we have two options. Firstly, the initramfs udev
>  can have different sets of rules, there's nothing wrong with that.
>  Secondly, before starting udev in the initramfs, we can do something
>  like:
>
>    for x in $disablemodules; do
>       echo "blacklist $x" >> /etc/modprobe.conf
>    done
>
>  /me shrugs

Still doesn't take into account the whole "load all dependencies"
thing though. Bummer.

-Dan