Ruminations on Udev, null and console
neal.p.murphy at alum.wpi.edu
Tue Feb 22 19:38:49 PST 2011
On Tuesday 22 February 2011 19:44:24 alupu at verizon.net wrote:
> Notes: 1. "cp ... console /dev" in 'udev' script doesn't work.
> (apparently, too late in the boot sequence.)
> 2. For reasons unknown, even if I start with the
> "metal" /dev empty, I end up with both "null"
> and "console" nodes in /dev at the end of boot.
> Go figure.
> The Udev police may get me one day but in the meantime I can
> have my full, CLEAN console log _and_ still use the excellent
> scripts Mr. Beekmans and all the other collaborators worked
> hard to design for our use and enjoyment. Thank you all.
Having integrated udev almost from scratch for my advanced version of
Smoothwall (I stole Debian's udev scripts), I've learned most of the ins and
outs of udev, devtmpfs and what the kernel offers.
If the option is enabled, the kernel has the ability to pre-populate /dev with
all devices it knows about. Mounting devtmpfs on /dev triggers the action. The
kernel will maintain its entries until something else touches them. Without
this kernel facility, /dev must be pre-populated with a few (yes, 'few')
nodes; /dev/pts usually needs to be made before mounting depts on it.
Once devtmpfs is mounted and either prepopulated by the kernel or the booting
system, udev can be started and triggered. It then walks the BIOS tree ins'ing
modules for all devices it finds. When it replaces a kernel-made node, the
kernel forgets about maintaining that node.
It ain't easy figgerin' this stuff out. I upgraded my dev version to 2.6.35
weeks ago, and only Sunday did I find the last piece of the puzzle to get
devtmpfs and udev working smoothly. The install bootup has no timing delays or
pauses. Just create a single lock file, a single spin waiting for udev to
start, a single wait for the lockfile to be erased, and a single wait for udev
to settle. The rest of startup goes like grass through a goose. Booting to HD
is even easier because USB isn't needed right off.
I haven't checked to see if the kernel will populate /dev without using
devtmpfs; it's working as-is: no sense in continuing the search for a
solution. :) But that's the reward: figuring it out relying on partial
documentation and improbable web search matches.
Put simply, *something* creates nodes in /dev:
- the build
- the installer
- the kernel
- the initramfs/initrd init script
- early userspace udev
- the rootfs boot script
- HD udev
My media builder no longer pre-populates /dev with anything. And if I haven't
already, I need to remove the stuff in /lib/udev used to prepopulate /dev. The
kernel now takes care of all that when devtmpfs is mounted.
I know my modernization of Smoothwall isn't LFS; I did borrow heavily from LFS
during the early efforts to get 2.6.26 and 2.6.32 working, just as Smoothwall
originally borrowed heavily from LFS when it was created years ago. But maybe
my perspective will help someone else learn a little more about early user
space, /dev and udev.
Speaking of the udev police...
[rant] Digressing a little, I have a bone to pick with Kay Seivers and Greg K-
H. Their attitude is that only symlinks should be used in /dev and created
from udev rules (for the most part), and those symlinks may only be named with
character sequences that are incomprehensible to ordinary humans. I believe
they've overlooked the human factors aspect: that people cannot quickly
pattern-match 50-byte filenames, that the kernel does not use symlink names in
its reports (only the actual /dev node name), your primary hard drive may be
hda today, sda tomorrow, sde the day after, and a couple other points. (Maybe
I mispeak a little; Squebian Deeze uses partition names; now I cannot find
*anywhere* the device associated with a FS! Aaaarrrgggh!) My bootup system
works, but I may well enhance the udev scripts to create additional disk names
(NAME+="..."), because hdX and sdX are now meaningless. I'll create
/dev/dsk[a-z] nodes based on the drive's short ID; the kernel is free to use
any name it wants to, and the admin will have a short, constant, neurally-
friendly name to use. In fact, kernel device names should be put in a
/dev/kernel tree, hidden from normal users. Human Factors needs to be brought
back to Linux in this respect, because humans (admins) need to be able to
quickly match node names against something their brains readily recognize as
much as the OS itself needs to be able to unambiguously recognize node names.
Don't get me wrong. Udev is great work; I really like it: it's eliminated a
couple hundred lines of startup script. It's just that now is the time to
start working human factors back into that equation to make Linux friendly
More information about the lfs-support