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

Dave Reisner d at falconindy.com
Wed Mar 30 16:58:29 EDT 2011

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:
> > /bin/mkdir -p /dev/{pts,shm}
> Good catch.
> > /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.
> -t

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 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.

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. 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.


More information about the arch-projects mailing list