On Fri, Feb 22, 2008 at 3:29 PM, Michal Soltys email@example.com 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"
That mod-blacklist.sh will be called on every uevent once - environment is not preserved between uevents (even with line proposed by Aaron), and must be fresh on every uevent.
Yes, this is something I *just* picked up on. That the environment is not preserved between event calls.
Is there particular reason, why you use monolithic single udev.rules file ?
Defaults in etc/udev/rules.d and etc/udev/packages are pretty clean and logical (standard rules from udev-118). Also they are split into xy-something.rules files so any specifics you need overridden in Archlinux, can be easily done so, with i.e. last_rule option and separate files. Easier for you to maintain, also easier for users to adjust for their particular needs
Let's solve one problem at a time here. Dan brought up the rules issue months ago. As it stands it hurts no one and is not the issues I am attempting to solve.
Compatiblity rules for loading scsi devices are no longer needed, as far as i know.
Report this on the bug tracker?