[arch-dev-public] Module blacklisting
dpmcgee at gmail.com
Sat Feb 23 09:20:05 EST 2008
On Sat, Feb 23, 2008 at 6:18 AM, Simo Leone <simo at archlinux.org> wrote:
> On Sat, Feb 23, 2008 at 11:12:51AM +0100, Xavier wrote:
> > On Fri, Feb 22, 2008 at 07:06:04PM -0600, Dan McGee wrote:
> > > Aaron covered it most of the way, but I just wanted to make it clear
> > > that every time you plug in a USB device or make any other hardware
> > > chage, udev triggers. If I've added a blacklisted module since the
> > > last time I booted (which may have been 50 days ago), then I want it
> > > to not load, and any processing of udev-related stuff outside of the
> > > udev framework would mean the module I added would not be blacklisted.
> > >
> > I was also thinking about this. I am afraid Aaron's ideas #2 and #3 don't
> > take care of that, since they build the blacklist in rc.sysinit, right?
> > Do you suggest reverting to the previous load-modules.sh then, which built
> > the blacklist every time? It doesn't sound very efficient, but how is it
> > possible to get the behavior you are describing otherwise?
> > http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/base/udev/load-modules.sh.diff?r1=1.9&r2=1.10&cvsroot=Core
> Hmmm... is it possible to implement some form of caching to solve this?
> If load-modules.sh took a quick md5sum or the MODULES array every time
> it runs, we could maintain current behavior, including blacklisting
> modules on a running system, at little or no cost, and quite
> transparently. This would at least make the dependency resolution only
> occur when the MODULES array happens to change.
Wowzers batman! Now we might as well do it the old way if we get this
complex and have to md5sum the damn file anyway. The point of this is
to keep multiple parses/reads of the file to a minimum, and md5sum is
another fork that we don't want.
There HAS to be a way to get udev to do something similar to what we
want, doesn't there?
More information about the arch-dev-public