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