[arch-dev-public] [signoff] udev 118-4

Dan McGee dpmcgee at gmail.com
Sat Mar 8 11:50:56 EST 2008


On Sat, Mar 8, 2008 at 10:34 AM, Tobias Powalowski <t.powa at gmx.de> wrote:
> Am Samstag, 8. März 2008 schrieb Dan McGee:
>
>
> > On Fri, Mar 7, 2008 at 4:58 PM, Aaron Griffin <aaronmgriffin at gmail.com>
>  wrote:
>  > > On Fri, Mar 7, 2008 at 4:50 PM, Thomas Bächler <thomas at archlinux.org>
>  wrote:
>  > >  >  Somehow, module loading is considerably faster here than before (even
>  > >  >  fast than with 118-2)
>  > >
>  > >  Yeah, there were 2 filesystem globbing based loops in there that were
>  > >  the major killers... for every module load it was doing a "ls
>  > >  /foo/bar/*/*/blah" which is ridiculously slow.
>  > >
>  > >  >  >  Module loading and all that should be back to sanity, with
>  > >  >  > slightly improved performance due to moving the framebuffer modules
>  > >  >  > out to a udev rule.
>  > >  >
>  > >  >  Doesn't work: intelfb is loaded here (but doesn't do anything, as
>  > >  >  intelfb never worked).
>  > >
>  > >  Weird. Same thing here. I assumed it was working because it was
>  > >  balking before when it tried to load nvidiafb, and then stopped
>  > >  freaking out. Apparently, though, nvidiafb is loaded here... and doing
>  > >  nothing. So this udev rule to skip the modalias load fails... hrm
>  >
>  > Works for me. Signoff i686.
>  >
>  > -Dan
>
>  no signoff
>  please add the framebuffer blacklist again to load-modules.sh

This is a terrible place for it, as I tried to explain on IRC. We
should not explicitly block a set of modules here. If we don't want
them, then why the hell do we even put them in our kernel?

If we do want them, then blacklist them correctly, which means people
can have the option of *not* blacklisting them.

>, it's not
>  possible to block framebuffer loading by udev rules.

Can you please explain why? Thanks.

>  framebuffer modules can cause weird issues for amd/ati and nvidia binary
>  drivers.

Sure, but not everyone uses a binary driver, and/or even xorg for that matter.

I feel like I'm just being a naysayer here without actually providing
a way to fix it, but this just seems like such a backwards way to fix
a problem to me.

-Dan


More information about the arch-dev-public mailing list