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

Aaron Griffin aaronmgriffin at gmail.com
Mon Mar 10 11:30:40 EDT 2008


On Sun, Mar 9, 2008 at 8:48 AM, Tobias Powalowski <t.powa at gmx.de> wrote:
> Am Sonntag, 9. März 2008 schrieb Aaron Griffin:
>  > Er? No. Modprobe loads it. udev calls a script that calls modprobe. We
>  > are not talking about where the CURRENT frambuffer blacklist exists,
>  > because I'm sure we all agree it is inefficient and broken. I'm
>  > talking about where it SHOULD be.
>
>  A file which belongs to a package that will affect also an other is bad.
>  Placing it in kernel package is bad because it might interfere with an other
>  kernel package.
>  Placing the file in udev affects all kernels the same and udev is our primary
>  module loader for now.

But, that's exactly my point. This is only an issue with OUR kernel.
If some custom kernel builds in different framebuffer modules, or even
only includes the one that is needed, then the blacklisting is moot.

The need to blacklist this modules is ONLY an artifact of the way we
build the kernel.

>  Just for your information, i have a full splitup rule udev here now.

I'm not sure what this means? The udev.rules? Shouldn't we just be
using (mostly) default rules from the udev source? I notice our
PKGBUILD deletes a lot of rules. Why don't we just... not delete
these, and then add our own like all the other distros do (i.e.
50-archlinux.rules)

>  about blacklisting, problem with modprobe.d/frambuffer would be if a
>  modprobe.conf is present it ignores the modprobe.d/ directory completly :(

Ew, I just noticed that. That's a little annoying that it only loads
one or the other. There are two solutions to that though:

1) Add "include /etc/modprobe.d" to the default modprobe.conf
2) Patch modprobe to not stop after the first thing found


More information about the arch-dev-public mailing list