Subject: Re: devfs, was Re: ptyfs fully working now...
To: Robert Elz <kre@munnari.OZ.AU>
From: Eric Haszlakiewicz <firstname.lastname@example.org>
Date: 11/26/2004 04:14:56
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