Tigran Aivazian wrote:
> Actually, jewish houses have two kitchen sinks - extremely useful (for
> having the wife assist with cooking) :)
Metaphor goes down the drain ... ;-)
> The very good thing about devfs is a rationalized namespace - things are
> where they should be.
For now ... besides, you could do that in /proc (or /kernel, /whatever)
too. I think there's value in trying to avoid cluttering devfs with
things that are very much non-devices.
The logic I see in the thread goes a bit like this:
/proc is a mess => not having things in /proc is good
=> moving things from procfs elsewhere is good
devfs is different from procfs
=> moving things into devfs is good
This ignores (at least) the following three alternative:
- maybe a clean solution does not exist (see below)
- there may be something other than /proc or /devfs (or course,
following this direction may just create a lot of *fs things
(memfs, busfs, kernelfs, netfs, ...) which just moves the problem
elsewhere)
- things could be restructured within /proc
If I look on /proc on one of my machines, I see the following types of
information:
- global peripheral hardware meta-data (dma, interrupts, iomem, ioports,
partitions, pci (obsolete))
- kernel meta-data (cmdline, devices, execdomains, filesystems, ksyms,
loadavg, locks, meminfo, misc (like /proc/devices), modules, mounts,
net, slabinfo, stat, swaps, sysvipc, uptime, version)
- bus with kernel and device meta-data, plus a little bit of non-meta
data (bus, scsi)
- other mixtures of kernel and device meta-data (atm/ (should maybe go
to net/atm/), tty)
- device meta-data (cpuinfo)
- empty top-level directories (driver, fs)
- kcore, similar to /dev/kmem
- kmsg, in a broad sense kernel meta-data, but I think it makes more
sense to consider it as non-meta data
- all kinds of read-write meta-data (sys)
The traditional inhabitants of /dev are things where the kernel has no
or only a rough idea of how their data is structured. Meta-information
is manipulated via ioctl. (/dev/sndstat being the obligatory exception,
but then it's not very traditional ...)
Among the things I've listed above, only kcore and kmem contain a
significant amount of non-meta data.
Furthermore, devfs allows for some nice structuring of information,
which parallels some of the things in procfs, e.g. /proc/scsi and
/dev{,fs}/scsi. Some other meta-information that is strongly related
to individual devices is in cpuinfo and in atm/. In the latter case,
things are complicated by the absence of a real device entry (ATM
interfaces are controled via networking ioctls, the device-specific
entries in /proc/atm are mainly for debugging).
There are a few complicated cases like /proc/pci, where I'm not sure
if they could make sense in devfs (busfs anybody ? ;-) For a really
tricky case, there's also /proc/openprom on SPARCs (at least on my
good old SS20 running 2.0.27).
What's left then is the large majority of /proc entries: kernel
meta-data and global peripheral meta-data. None of them have a very
natural place in /dev or a devfs that tries to maintain semantics
similar to a traditional /dev. So the result of moving them would
probably be just a bastardized devfs, like the bastardized procfs
we have right now.
Finally, before changing even the first entry, please consider which
programs and scripts may have used that entry in /proc for ages.
IMHO, it's very bad style if you have to tell people that, in order
to use 2.4, they have to upgrade dozens of utilities and to check
scripts they may have written years ago and long since forgotten.
- Werner
P.S. Personally, I think, among the items listed above, kcore and kmsg
should probably move to devfs, /proc/scsi may be a good candidate
for a merge info devfs, cpuinfo may be usefully merged into
/devfs/cpu if the latter has per-CPU subdirectories, and the rest
should stay in procfs.
-- _________________________________________________________________________ / Werner Almesberger, ICA, EPFL, CH werner.almesberger@ica.epfl.ch / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/- 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/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:33 EST