On Sun, Mar 11, 2012 at 8:17 AM, Alan McKinnon <alan.mckin...@gmail.com> wrote: > On Sun, 11 Mar 2012 07:27:05 -0400 (EDT) > Daddy <da...@happypenguincomputers.com> wrote: > >> On March 11, 2012 at 5:09 AM Walter Dnes <waltd...@waltdnes.org> >> wrote: >> >> > This revision makes 2 changes... >> > >> > A) The removal of udev is now standard instead of optional. >> > udev-181 and higher will be pulling in kmod, and anything else that >> > kmod depends on. Removing udev will avoid unnecessary cruft on >> > your machine. >> > >> > B) Splitting up step 3) into 3a) and 3b) for greater clarity as >> > requested in user feedback. >> > >> > The usual warnings apply... >> > * this is a beta >> > * use a spare test machine >> > * if you don't follow the instructions correctly, the result might >> > be an unbootable linux >> > * even if you do follow instructions, the result might be an >> > unbootable linux >> > >> > >> > 1) Set up your kernel to support and automount a devtmpfs >> > filesystem at /dev >> > >> > * If you prefer to edit .config directly, set >> > CONFIG_DEVTMPFS=y and CONFIG_DEVTMPFS_MOUNT=y >> > >> > * If you prefer "make menuconfig", the route is as shown below. >> > Note that the "Autount devtmpfs..." option won't appear until you >> > enable "Maintain a devtmpf..." option. >> > >> > make menuconfig >> > Device Drivers ---> >> > Generic Driver Options ---> >> > [*] Maintain a devtmpfs filesystem to mount at /dev >> > [*] Automount devtmpfs at /dev, after the kernel mounted the >> rootfs >> > >> > Once you've made the changes, rebuild the kernel. >> > >> > >> > 2) Set up for emerging busybox. busybox requires the "mdev" flag in >> > this situation. The "static" flag is probably also a good idea. In >> > file /etc/portage/package.use add the line >> > >> > sys-apps/busybox static mdev >> > >> > Now, "emerge busybox" >> > >> > >> > 3 a) Create /sbin/linuxrc containing at least >> > >> > #!/bin/busybox ash >> > mount -t proc proc /proc >> > mount -t sysfs sysfs /sys >> > exec /sbin/init >> > >> > This should be enough for most users. If you have an unusual >> > setup, you may need additional stuff in there. Remember to >> > "chmod 744 /sbin/linuxrc" to make it executable. >> > >> > In the bootloader "append" line, include "init=/sbin/linuxrc". If >> > you're using lilo remember to re-run lilo to implement the >> > changes. If you're using another bootloader, make the equivalant >> > initialization. >> > >> > >> > 4) Remove udev from the services list, and replace it with mdev. >> > Type the following 2 commands at the command line >> > rc-update del udev sysinit >> > rc-update add mdev sysinit >> > >> > >> > 5) reboot to your new kernel. You're now running without using >> > udev. >> > >> > >> > 6) Remove udev as per the following instructions... >> > >> > * execute the following command at the commandline >> > emerge --unmerge sys-fs/udev >> > >> > * In file /atc/portage/package.mask, append the line >> > sys-fs/udev >> > Create the file if it doesn't already exist. You now have a >> > totally udev-free machine >> > >> > -- >> > Walter Dnes <waltd...@waltdnes.org> >> > >> >> Having personally long considered Lennart Poettering a 'spawn of the >> devil' my question is ... is this your reaction to systemd? > > > No, it's his reaction to the fantastical amount of kitchen-sinking > going on surrounding udev. Most specifically, it's the recent > "requirement" foisted on the udev-using community to require > either /usr to be part of / or to use an initramfs. > > Walter simply wants to show that mdev is a suitable replacement for > udev in simple environments eg embedded, simple desktops without > complex hotplug requirements, and servers. > > Canek will no doubt chip in about how this is the way things are going, > it is inevitable, the boot sequence is becoming complex and various > other rehashings of what's coming out of udev upstream.
No, I will not ;) As I have said before, I admire a lot what Walter et al. are doing, and as I always will say, this is how our community works: people writing the code (as Walter is doing) are the ones that get things done. This is the correct (and only) way to address a problem (perceived or real) with the current status: write the code that does the thing the way you want it. Complaining and crying that you don't like the direction some part of the stack is taking is at best a waste of time, and at worst idiotic. Actually doing something about it (as Walter is doing) is the smart thing to do. I personally will not use Walt's work. Not in my desktop, laptop, nor in my servers or embedded systems (I don't know if my Media Center qualifies as "embedded", if I'm truthful); they all run amazingly well with systemd. But that's my decision: if anybody else wants to go the mdev route, that's their absolute right. This is open source: code talks. If anyone with enough interest and capabilities wants to implement any feature (or anti feature) they want, they will. That's what Walter is doing, and I sincerely salute that effort. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
