Date:        Fri, 26 Nov 2004 04:14:56 -0600
    From:        Eric Haszlakiewicz <erh@nimenees.com>
    Message-ID:  <20041126101456.GA4268@diana.nimenees.com>

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

atimes are updated frequently - none of the formats I've seen mentioned
(and I am still am > 1200 messages behind current on list mail, so
I might still be missing things) are really amenable to that happening
a lot.   Changing owners/permissions/... of a device probably happens
once a month at most sites (if that) so it doesn't really matter how
efficiently that kind of update happens to the permanent storage method.

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

Then don't remove it, it doesn't do much harm (most of it was ptys anyway,
and that part looks to be nicely gone already).

  | A few rationales for devfs:
  | *) Reduce admin work to add a new device

I have no problem with the kernel scanning /dev as it starts, then
creating entries for any device it finds that isn't there already.
If you're going to have a dynamic devfs type thing, then you're
obviously already going to have to have the kernel know suitable names
to use (which it doesn't need now), and obviously the kernel is already
able to create device inodes (it does now in response to a mknod() sys
call) so nothing particularly new is needed here.

  | *) eliminate device major/minor allocation issues (esp. useful for third
  | 	party modules that might want to create devices)

Changing from major/minor to something else is pretty much independent of
how the user file name (device file name) -> kernel mapping gets done,
which is what devfs is all about really.   That's one level lower.   I don't
care what is in a device inode to link it to the driver.

I know that you mean for it to be dynamic, but if you're going to have
any kind of preserved properties (over reboots) for devices, then you have
to have some kind of stable naming scheme.   Whatever that is can simply
be used in a device inode as far as I'm concerned (changing from major/minor
is going to have all kinds of upgrade and portability issues - what to
put in pax (or cpio) files for devices, handling old dumps, ... but that
can all be overcome, somehow).

  | *) it allows more flexible device namings (e.g. to better support wedges)

Huh?

  | *) Provide a way to easily see what devices are currently available

OK, I'll admit a devfs is good for that, just as procfs is good to see
what processes are running.   Make one just like procfs, and I won't
complain.   I doubt many people would bother using it though - I mostly
already know what hardware is on my systems, I connected it after all...

  | *) improve security by making it possible to make it impossible to have a
  | 	usable device node anywhere else on the system

I agree totally with der Mouse - this isn't security, it is a disaster.
As long as only root can create device nodes, (and nodev exists for NFS
mounts, and other portable devices), there is no problem - but this would
be a big loss (including for chroot'd environments, which I have seen
mentioned already).

  | *) reduce clutter

If the kernel is able to mknod by itself, simply starting with an empty
/dev, and allowing it to create nodes as they're found wouldn't leave much
clutter around.   After they're created, they should be just inodes
referenced from a directory though, as they are now.   Whether they're the
same format as the current ones (type 0020000 for c & 0060000 for b)
or not doesn't really matter.

kre