Ruminations on Udev, null and console
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
> # 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?
More information about the lfs-support