[arch-dev-public] Module blacklisting

[Dan McGee]

On Tue, Feb 26, 2008 at 11:59 AM, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> On Tue, Feb 26, 2008 at 11:54 AM, Dan McGee <dpmcgee at gmail.com> wrote:
>  > On Tue, Feb 26, 2008 at 11:30 AM, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
>  >  >
>  >  > On Tue, Feb 26, 2008 at 11:15 AM, Daniel Isenmann
>  >  >  <daniel.isenmann at gmx.de> wrote:
>  >  >  > I'm a little bit confused right now. How can I blacklist modules. I
>  >  >  >  have test both, MOD_BLACKLIST=(...) and MODULES=(!...), but both don't
>  >  >  >  work. udev loads every module which can be loaded. For example I
>  >  >  >  blacklist nvidiafb, but udev loads it. Packages are up2date with
>  >  >  >  testing repo.
>  >  >  >
>  >  >  >  Can someone please explain it or the status is on this topic?
>  >  >
>  >  >  The status is that I haven't gotten a concise answer. On this. For the
>  >  >  time being, I think we should do the following:
>  >  >
>  >  >  a) Rebuild udev 118 with start_udev in there, for the people who keep
>  >  >  their systems in some goofy limbo state by only updating singular
>  >  >  packages at a time
>  >
>  >  And add a big old echo at the top saying "You are using start_dev.
>  >  This script will be removed in a future release!"
>
>  Doesn't work. It's run with 2>&1 >/dev/null, which is very good at
>  keeping users uninformed of what's going on.

Well that is dumb. Shoot.

>  >  >  c) Remove framebuffer module loading from the load-modules script (it
>  >  >  should never have been there in the first place).
>  >  Agreed. What are the hotpoints in this script as well? Something like
>  >  this seems inefficient:
>  >  i="$(/sbin/modprobe -i --show-depends $1 | sed "s#^insmod
>  >  /lib.*/\(.*\)\.ko.*#\1#g" | sed 's|-|_|g')"
>  >
>  >  We invoke 3 subprocesses here (modprobe, sed, and sed). Surely the two
>  >  seds can be combined.
>
>  already done locally.
>
>
>  >  See a trend here? So we have the following in one run of
>  >  load-modules.sh (if we look back at the version packaged with 116):
>
>  Good catch with all the seds... but ummm.... how about we NOT worry
>  about optimizing a script we'd like to get rid of? I'm sure start_udev
>  could use some cleanup, want to do that too?

start_udev isn't even used by the curent initscripts though, so thats
a different point than this one.

Yes, I feel like maybe a short and sweet C program would be better,
but for now cleaning some things up makes sense and will probably have
an effect on the loading events time, thats all. If I can spend a half
hour making it a little better and/or more efficient, I think that is
time well spent, even if it is going to eventually be scrapped.

-Dan