Ruminations on Udev, null and console

DJ Lucas dj at linuxfromscratch.org
Sun Feb 27 00:36:08 PST 2011


On 02/25/2011 04:38 PM, Bruce Dubbs wrote:
> 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
>

Interesting. I hadn't noticed these changes. I had seen the extra 
configuration item, but didn't put two and two together and simply 
ignored it as unnecessary baggage (fortunately it actually is with our 
current boot scripts). Guess I'm getting a little slow. I still haven't 
looked at it yet, just working from Neal's comments.

> 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 comment was only to say that it is now unnecessary.

> 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.
>

Actually, we do. The kernel must be built with tmpfs support as required 
by udev. Why not extend that and require that devtmpfs support be 
built-in as well?

Assuming it works, and I've no reason to doubt that it does (only that I 
haven't tested myself), we remove a few lines from the udev script, the 
mountkernfs script gets a change, a new recommendation is added to the 
book where the current one is, and a small section of the book is 
rendered unnecessary - yes the information gets locked away in a little 
black box, but IMO, that happened 5 years ago when the makedev script 
went away. The concept of device nodes (and even the devices.txt 
included with the kernel) is probably already lost to the younger users 
until it becomes necessary to create one that udev knows nothing about 
(and those are few and far between). Nothing really lost here, and a 
small gain in efficiency. The old race car bit fits nicely here: don't 
look for 1 place to loose 100 pounds; look for 100 places to loose 1 
pound. :-)

-- DJ Lucas




More information about the lfs-support mailing list