On Tue, Feb 26, 2008 at 11:59 AM, Aaron Griffin <[EMAIL PROTECTED]> wrote: > On Tue, Feb 26, 2008 at 11:54 AM, Dan McGee <[EMAIL PROTECTED]> wrote: > > On Tue, Feb 26, 2008 at 11:30 AM, Aaron Griffin <[EMAIL PROTECTED]> wrote: > > > > > > On Tue, Feb 26, 2008 at 11:15 AM, Daniel Isenmann > > > <[EMAIL PROTECTED]> 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
