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 On Fri, Feb 22, 2008 at 3:47 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Fri, Feb 22, 2008 at 3:29 PM, Michal Soltys <soltys@ziu.info> wrote:
modprobe supports blacklisting itself in modprobe.conf (to be precise - it blacklists all aliases for specified modules, which is exactly what's needed here). You can use raw modprobe and probably speed up things nicely, without any extra scripts.
modprobe's blacklisting is terrible. It is meant to be used with conflicting aliases. Here's the actual usecase:
module foo contains an alias "blah" module bar contains an alias "blah"
If I modprobe blah, it doesn't know which to do. So, blacklisting "bar" tells modprobe ONLY to ignore the aliases exposed by bar. I can still modprobe bar by a non-alias name, and I can still load bar as a dependent module.
So, the way we handle it, is such that blacklisting "bar" makes it so that no other module that depends on bar can load it without you saying so. This is the main benefit. Want to shut off sound? blacklist "snd" or "soundcore"