Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5

[Alan McKinnon]

On Sun, 11 Mar 2012 07:27:05 -0400 (EDT)
Daddy <daddy@×××××××××××××××××××××.com> wrote:

> On March 11, 2012 at 5:09 AM Walter Dnes <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 <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.

However, something needs to be pointed out in that regard. What udev
upstream is saying is probably quite true, but only within the limits
of the environment in which they work and udev is designed to handle -
sophisticated desktops. The three cases I mentioned are perfectly valid
use-cases, comprise a large percentage of the Linux installed base,
should be catered to and have no need of the sophistication current
udev aims to provide.

As such, mdev is a good fit and we can add Walter to the long list of
people before him who selflessly worked to make our software work
better.

>
> One minor typo to point out:
>
> /atc/portage/package.mask should be /etc/portage/package.mask
>
> I just joined this list last week, but might consider sacrificing some
> hardware to join your endeavor if you need more testers.


Welcome to the list, you'll soon get to know all the personalities
here. We have at least one of everything - class clowns, old farts,
newbies, voices of reason, influential devs and even the occasional
fellow who knows what he's talking about.

:-)




-- 
Alan McKinnnon
alan.mckinnon@×××××.com