[arch-projects] [PATCH 10/10] dev: create pts and shm directories

[Tom Gundersen]

I'm cc'ing Tobias (udev maintainer) in case he is not on the list.

On Wed, Mar 30, 2011 at 10:58 PM, Dave Reisner <d at falconindy.com> wrote:
> On Wed, Mar 30, 2011 at 09:06:17PM +0200, Tom Gundersen wrote:
>> On Wed, Mar 30, 2011 at 8:54 PM, Dave Reisner <d at falconindy.com> wrote:
>> > /eyeballs /lib/udev/load-modules.sh
>>
>> Yes, that should go (as it slows down boot considerably and changes
>> the semantics of udev in a non-trivial way), but I don't know enough
>> about how it works to know what would be lost.
>
> It'd be lovely if we could adopt the upstream /etc/modprobe.d hierarchy.
> I've always wondered why the KISS solution in this case was interpreted
> as: "create an wrapper around a magical bash array to intercept every
> modprobe call" when using 'install foomod /bin/false' works just as
> well.

I don't know the historic reasons, my guess is that the script was
added when udev couldn't do the blacklisting it can do today. The
biggest challenge I see would be to figure out what the script can do
that the upstream blacklisting cannot. Is there any documentation on
this that I have missed?

> I tried to slim this script down, and while I was able to
> reproduce it in about half the SLOC (sans logging), it was susceptible
> to a few early boot issues and moreover, had zero effect on speed.

I think the main slowdown comes from spawning bash all the time (the
script itself is not that big), so that makes sense.

> This is where this ML is going to be fun: I do notice that
> load-modules.sh also in mkinitcpio (which doesn't, nor could it include
> /etc/rc.conf due to the bash dependency). mkinitcpio has blacklisting
> capabilities via the kernel cmdline and through the aforementioned
> /etc/modprobe.d hierarchy.
>
> I am happy to provide patchwork to remove this mess and replace it with
> something slightly more sane (while still retaining the MODULES array).
> Tom, I'm thinking of something very much along the lines of what we do
> for initscripts-systemd on shutdown.

The script Dave is referring to is meant to be run at shutdown, reads
rc.conf and saves the MODULES array (among other things) in a format
that udev knows how to read on boot.

It would be neat if this script could be made to work the same in
systemd and initscripts so we don't get any duplication (I guess it
should already work in both settings).

> My only hangup is what to do with
> the quirks we have in our arch.rules files. I'm not familiar with the
> circumstances under which those were added, nor the repercussions of
> removing them.

That's independent from removing load-modules.sh though?

Cheers,

Tom