[arch-dev-public] Module blacklisting
aaronmgriffin at gmail.com
Mon Feb 25 18:15:42 EST 2008
On Sat, Feb 23, 2008 at 8:20 AM, Dan McGee <dpmcgee at gmail.com> wrote:
> 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?
This is exactly my point. It's getting retardedly complex.
To answer Roman's question as to why 116 and 118 differ in speeds:
116 rejiggered the module blacklist (poorly, I might add) on every module load.
118 *tried* to do it once when udev started, but I was unaware that
the environment is flushed _for each device_ so my "solution" actually
made things slower (the blacklist was rebuild for every device, not
just those that load modules).
We can go back to the 116 way of loading modules and building the
blacklist everytime, but we can make a few changes:
a) framebuffer modules blacklisted in there is a very bad idea - move
those to a udev rule similar to:
b) optimize the nested loops better. For right now, for each module,
we loop over each dependent module, and compare that to each blacklist
module... it's gross. I modified it to use \<word\> based grep at some
point, to convert it to one loop, but it's still a tad slow.
c) Maybe even write some small C app that outputs our full blacklist,
to optimize that messy part.
More information about the arch-dev-public