Ruminations on Udev, null and console

Neal Murphy neal.p.murphy at
Tue Feb 22 19:38:49 PST 2011

On Tuesday 22 February 2011 19:44:24 alupu at 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 mailing list