lkml.org 
[lkml]   [1999]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: UUIDs (and devfs and major/minor numbers)
   Date: Tue, 15 Jun 1999 15:25:49 +1000
From: Richard Gooch <rgooch@atnf.csiro.au>

> This argument invites scrapping all of procfs.
Yes. This is one of the most annoying things in this debate, and seems
very hypocritical. If people want to use the purist argument against
devfs, then they should be consistent. Get rid of procfs (at least,
all the non-process stuff), autofs and knfsd.

The purist argument is not that synthetic filesystems are automatically
bad. For example, the rationale behind knfsd is one of performance as
well as some correctness issues. Whether a sysctl vs. the non-process
procfs approach is a better one is actually an interesting discussion,
and that fact that we have both is a botch, but it doesn't necessarily
mean we should eliminate all of /proc. Certainly the process related
stuff can't be done any other way.

Look to devfs as a way of cleaning up procfs instead. Move all the
non-process stuff into devfs. That way we can get back to a procfs the
way it was intended.

Well, no, that doesn't work, since there plenty of non-process stuff
which doesn't fit into a devfs mounted in /dev. Now, if you were to
make an argument for a /kern that had the non-related process stuff, and
perhaps one of the things in /kern was something like was is in
Solaris's /devices directory, that might be interesting. What Solaris
has in /devices are names which are designed to be unique and
explicit about what they are attached to. For example, we might have a
device name vaguely like:

/kernel/devices/pci/adaptec2980_0/id0/lun0/part1

...and then having a user-mode daemon make symlinks from /dev/sda1, or
/dev/disks/<fslabel>, or /dev/scsi/disks/*, or whatever new experimental
naming scheme that people want to experiment with. That's definitely
policy that shouldn't be enforced by the kernel, so we would have a
user-mode daemon that can consult a database (ala lspci, etc.) which can
be changed when people want to experiment with different structures and
hierarchies in /dev. This may or may not be the best approach, but I
believe it's better than the current devfs approach.
The bottom line for me is that kernel already has a very well developed
backing store of files in /dev, and that's an ext2 or a minix
filesystem. If you use that, then you don't need the tar file kludge at
shutdown to preserve permissions. It's also clear that the decision of
what the names of files in /dev really should be done in user-space, and
should possibly consult a configuration file. There is clearly some
functionality in devfs which is useful; but something which overmounts
/dev really is the wrong long-term approach IMO. Maybe a
/kernel/devices approach, combined with a reorg of the non-process parts
of /proc is the right approach, but I don't have a strong opinion about
that. In the end, even if we agree that /proc should be cleaned up,
that doesn't mean we should put other code which makes similar design
choices/mistakes into the kernel. It isn't hypocritical to say that
both approaches are bad, and while we do need to fix /proc at some
point, that isn't an excuse for devfs.


- Ted


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:52    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site