udev in initrd

[Jeremy Katz]

On Fri, 2004-05-28 at 18:05 +0200, Thomas Woerner wrote:
> There are test packages in http://people.redhat.com/twoerner/UDEV/ for using 
> udev in initrd with persistent devices.

Note, all of my comments here are just from looking at the changes and
not actually trying them yet.  I'll try to get to that later tonight,
though.

> Information about udev and the new mkinitrd
> -------------------------------------------
> 
> The benefit of udev is that there are only those device nodes which are bound 
> to devices in your computer and that you can have additional device naming 
> schemes like 'by label' or 'by id'.
> However there is a small problem with dynamic device nodes: For all devices, 
> which are not recognized before a specific module is loaded, there will be no 
> device node until the driver is loaded either by hand of by a program. kudzu 
> would be a good candidate for this, but it has to be started earlier, then.

The smaller /dev is of arguable benefit.  Users shouldn't be looking
in /dev directly really since even with udev, it's going to be fairly
ugly.  And as of yet, I haven't seen a "good" other device naming
scheme.  I think that this is vitally important to any attempt to
actually switching to use udev.  If we keep the same device naming, I
really see little benefit here.

> udev is using helpers for additional device naming schemes, which are c 
> programs or shell scripts. Therefore it is necessary to put tools like sed, 
> awk, grep and so on in the initrd. These programs are not small and the initrd 
> would be very big. The solution for this is to use a static compiled busybox, 
> which combines tiny versions of many utilities into a single executable.

What helpers specifically?  Can we simplify these to not require lots of
additional tools?  Or use a scheme that doesn't require lots of
different additional tools?  We don't necessarily have to support every
conceivable naming scheme in the world for within the initrd.

> Thus the new mkinitrd is using busybox for the initrd with udev support. 
> Disabling udev results in a normal initrd with nash. It is easy to modify 
> mkinitrd to build the normal initrd with busybox.

Hmmm, this uglifies mkinitrd a lot.  Having two completely separate
paths for the initrd is completely unmaintainable for the long-term.  I
think that I'd rather cut the busybox down to just the minimal set of
tools needed and then still use nash as the base shell.  And actually,
getting it so that we're using the main busybox instead of
busybox-initrd would be nice (I need to look at the anaconda specific
config differences so that I can try to merge those to not require a
weird subpackage).  This would be especially as there are a few
"features" in nash that aren't going to be in a standard shell (things
like handling of quiet mode, the simple mkdmnod present, etc)

> udev initrd - using busybox and ramfs
> -------------------------------------
> 1) mount /proc and /sys
> 2) mount /dev as ramfs
> 3) create initial devices (eg: console, null, zero, loopX) and links for std
>     files

This looks/feels a little ugly.  But there's probably some shell that
could make it a little bit cleaner.

> 4) start udev, use udevsend as hotplug
> 5) load modules (eg. controller, filesystem)
> 6) umount /sys
> 7) locate root device

I don't like this at all.  For one thing, doesn't it currently break
with root=LABEL=/?  Is there a reason not to just use /dev/root here as
we currently do?

> 8) mount system root on /sysroot
> 9) bind /dev to /sysroot [UDEV_KEEP_DEV="yes"]
> 10) change root to /sysroot and initrd to /sysroot/initrd
> 11) umount /initrd/proc
> 12) umount /initrd/dev [UDEV_KEEP_DEV="yes"]

Having the case of using udev in your initrd but not using it for /dev
on your installed system seems like a fairly ridiculous case that just
complicates things.  Either you're using udev for the system or not.
This then lets us drop out the /etc/sysconfig/udev handling from within
mkinitrd.

Jeremy