Ruminations on Udev, null and console

Bruce Dubbs bruce.dubbs at gmail.com
Fri Feb 25 12:02:23 PST 2011


alupu at verizon.net wrote:

> 3.2.  The PROBLEM (the actual object of the OP) has been
> 
> << my worries started recently when _finally_ a [light] bulb went
>   [off] in my head on reading
> 
>    # Create some devices and directories that Udev cannot handle
>    # due to them being required very early in the boot process,
>    # or by Udev itself:
>         ...
>       mknod -m0666 /lib/udev/devices/null c 1 3
> 
>  in the LFS udev-166 procedure
> 
> AND
> 
>    # Copy the only static device node that Udev >= 155 doesn't
>    # handle to /dev
>        cp -a /lib/udev/devices/null /dev
> 
>  in the latest "udev" script. >>
> 
> In other words, the above two commands are in contradiction to 6.2.21
> (as cited by you), and << redundant (and _misleading_) >>.
> I.e., in yet some other words, the author(s) of the "udev" script and
> "udev" installation procedure (this fallacy goes back quite a few
> iterations from 166) should re-read 6.2.21 even harder than me.
> In delicate terms, there should be a co-ordination somewhere.

I haven't looked at this code in quite a while, but I don't see these 
instructions as contradictory.  It looks like the process is:

1.  Use null and console at the start.
2.  Mount a tmpfs on /dev hiding the original null and console devices.
3.  Create all new devices, including null, on the tmpfs via udev and 
the boot script.

Newer versions of udev or the kernel may make some of these procedures 
unnecessary, but they don't hurt anything.  A device node takes up 1 
directory entry and no additional space.

I don't understand what appears to be a sense of urgency in your post. 
What are the drawbacks of the procedure as is?

   -- Bruce



More information about the lfs-support mailing list