On Wed, 23 Feb 2000 almesber@lrc.di.epfl.ch wrote:
> Maybe, but right now it certainly isn't. Trying to migrate everything
> to devfs is likely to leave you with half of the neither-process-nor-
> device stuff in /proc and the rest in /devfs, leaving you with two
> kitchen sinks. Please don't try to do this.
Actually, jewish houses have two kitchen sinks - extremely useful (for
having the wife assist with cooking) :)
> Besides, I don't quite understand all the fuss about /proc. It's not
> overly hard to distinguish process and non-process entries (isdigit),
> and I doubt that readdir'ing over the respective wrong kind is much of
> a performance issue. So moving them elsewhere may at best create a lot
> of forced upgrades (i.e. basically everything reading /proc also reads
> non-process entries).
>
> Some people argue that the non-process entries in /proc should
> disappear entirely. I don't want to re-iterate this particular
> discussion, just let me say that a large percentage of people putting
> things into /proc disagree with this view :-) Also let me point out
> that /proc entries are typically self-contained, which is a major
> advantage for deployment.
The very good thing about devfs is a rationalized namespace - things are
where they should be. I agree that in principle, it does not matter
whether we have a /proc/cpuinfo or /dev/cpu/info if both files behave
identically, but groupping logically related things together is a good
idea, instead of just putting a lot of stuff in the root of /proc and some
things group into subdirectories thereof.
After reading devfs/README and the code I am starting to be on Richard's
side that "tough, use devfs" is not such a bad idea, after all :)
Regards,
Tigran.
-
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:32 EST