[arch-general] [arch-dev-public] [signoff] udev 118-2

[Aaron Griffin]

On Fri, Feb 22, 2008 at 3:29 PM, Michal Soltys <soltys at 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"

>  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?