Messages in this thread | | | Date | Tue, 15 Jun 1999 23:18:11 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: 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/
| |