Ruminations on Udev, null and console

Bruce Dubbs bruce.dubbs at gmail.com
Fri Feb 25 14:38:25 PST 2011


Neal Murphy wrote:
> On Friday 25 February 2011 15:02:23 Bruce Dubbs wrote:
>> 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?
> 
> You are quite right. Your three steps work fine and hurt nothing. The drawback 
> is slightly elevated code complexity in building and preparing the system, 
> booting it, as well as the effort to keep and maintain that code.
> 
> Enabling CONFIG_DEVTMPFS_MOUNT in the kernel (2.6.32+, I believe) reduces the 
> steps to:
>   1. Mount devtmpfs on /dev; the kernel populates it with devices it knows
>   2. Run udev to 'take over' those nodes and populate it with everything else

I don't understand your comment about effort to keep and maintain the 
code.  There were a couple of minor text changes about 7 months ago and 
prior to that, basically no changes for four years.

The biggest problem I see for your methodology is that it requires a 
specific kernel configuration.  We don't do that anywhere in the book. 
We do mention some optional configurations in Chapter 8.

Your methodology is significantly different from LFS.  You mention using
klibc and initramfs, neither of which are mentioned in the book.

Your modifications are great.  After all, it's your distro, and you get 
to make your rules.

I just don't think your methods are appropriate for LFS.

   -- Bruce



More information about the lfs-support mailing list