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

[Michal Soltys]

Aaron Griffin wrote:
> 
> Idea #2:
>    $ mv /etc/udev/rules.d/00-load-blacklist.rules
> /etc/udev/rules.d/00-load-blacklist.rules.disabled
>    in /etc/rc.sysinit, add ". /lib/udev/mod-blacklist.sh" and "export
> BLACKLSIT MOD_AUTOLOAD" right before the udevd --daemon call
>    comment out the echo lines in the mod-blacklist script if you care
> 
> Hopefully the environment vars that udev sees are also seen by scripts
> that it executes...
> 

Sorry for crossposting, but I couldn't not add some remarks :)

Following discussion on dev mailing list regarding new udev and initscripts, 
I have one question - why rely on separate blacklist defined in rc.conf ?

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.

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.

Btw - you can monitor environment with udevmonitor --env

Other remarks:

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

Compatiblity rules for loading scsi devices are no longer needed, as far as 
i know.

Few others can be skipped as well (check 80-drivers.rules for current state, 
also gentoo 30-kernel-compat.rules for interesting reference).


Cheers