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 -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
