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
