On Fri, Nov 26, 2004 at 04:08:09PM +0700, Robert Elz wrote:
> Schemes which simply invent nodes (of some kind) at boot, even if they apply
> owner/permission fixes from some file that holds this information, just
> aren't good enough.   None of that kind of thing is suitable for holding
> data that is subject to being updated (by the kernel) as frequently as an
> inode atime.

	Why not?  What's wrong with having the kernel write out timestamp
data along with all the other info about a device node?

> If the only real rational for a devfs is to clean up clutter in /dev
> (for those too lazy to cleanit up themselves, and who nevertheless care

	The problems with just going in and "cleaning up clutter" are
	*) It's difficult and time consuming to figure out what to remove
	*) if you do remove clutter, you then have to put it back if you add
		a new device.
	The running kernel has all the information necessary to do both
of these tasks without needing to waste a person's time doing it manually.
Lazy is good.  If I go and configure a disk named wd64 in the kernel config
having to also change /dev is unnecessary busywork.

A few rationales for devfs:
*) Reduce admin work to add a new device
*) eliminate device major/minor allocation issues (esp. useful for third
	party modules that might want to create devices)
*) it allows more flexible device namings (e.g. to better support wedges)
*) Provide a way to easily see what devices are currently available
*) improve security by making it possible to make it impossible to have a
	usable device node anywhere else on the system 
*) reduce clutter

eric