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
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"
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?
Aaron Griffin wrote:
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.
Well, from udev perspective, modprobe by nonalias name is not an issue (or is it ?).
About module dependency though - good point, I missed that :(
As for your #3 idea, you can store that blacklist file in i.e. /dev/.udev/blacklist, which you can remove later, after udev processing.
Also, rc.sysinit script you could add extra trigger pass for failed events, i.e.
if [ -d /dev/.udev/failed ]; then udevadm trigger --retry-failed udevadm settle fi
(although conditional is not really necessary)
I often have some failed ones, which can be easily retriggered this way. Some other distros do that in their initscripts as well.
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.
fair enough :)
Cheers
(hope I helped tiny bit ;)
Michal Soltys wrote:
As for your #3 idea, you can store that blacklist file in i.e. /dev/.udev/blacklist, which you can remove later, after udev processing.
Also, rc.sysinit script you could add extra trigger pass for failed events, i.e.
Actually, let it stay there. /dev/.udev/ is always present after udevd is started, and is never removed. So just generate the blacklist early in rc.sysinit, like you suggested, and keep it there - this way it can be reused whenever script responsbile for loading modules is called.
Cheers
On Sat, Feb 23, 2008 at 11:09:03PM +0100, Michal Soltys wrote:
Michal Soltys wrote:
As for your #3 idea, you can store that blacklist file in i.e. /dev/.udev/blacklist, which you can remove later, after udev processing.
Also, rc.sysinit script you could add extra trigger pass for failed events, i.e.
Actually, let it stay there. /dev/.udev/ is always present after udevd is started, and is never removed. So just generate the blacklist early in rc.sysinit, like you suggested, and keep it there - this way it can be reused whenever script responsbile for loading modules is called.
What if you blacklist a module after booting, then plug in some hardware? http://www.archlinux.org/pipermail/arch-dev-public/2008-February/004941.html
The previous udev package still looks like the most acceptable way.
Xavier wrote:
What if you blacklist a module after booting, then plug in some hardware? http://www.archlinux.org/pipermail/arch-dev-public/2008-February/004941.html
The previous udev package still looks like the most acceptable way.
Ahh, yes, you're right. There would have to be some script to redo the blacklist file after every alteration.
On a side note - you can nicely blacklist a device through udev rules, instead of blocking some module(s) from loading. For example:
06-early-block.rules
SUBSYSTEM=="pci", ATTR{vendor}=="0x8086", ATTR{device}=="0x24d5", OPTIONS="ignore_device"
This one would block sound (ich5) on one of my machines.
arch-general@lists.archlinux.org