Re: /proc and /kern
Alain Williams (addw@phcomp.co.uk)
Thu, 3 Dec 1998 21:39:10 +0000
On Thu, Dec 03, 1998 at 10:55:30AM +0000, Tigran Aivazian wrote:
> There are probably many advantages to this, but the more obvious ones are:
>
> a) It is easier (for user program) to process /proc under assumption that
> we won't find anything "modern", i.e. anything other a plain old <pid>
> directory.
>
> b) This is the way it is done under UnixWare, i.e. /proc and
> /system/processor (/processorfs) are separate filesystems and /proc only
> contains <pid> directories.
>
> c) Different permission semantics can be implemented, e.g. one could allow
> creation of FIFOs in /kern but not in /proc to cater for cases like the
> recently-discussed /proc/pci compatibility issue.
> ......
> > I realize that this could cause a major flag day since lots of stuff
> > depends on /proc, so I propose to make it configurable (either compile
> > time configurable or maybe mount time if possible), so that initially
> > people would only turn it on when they were trying to find out what
> > would break.
It need not break applications: all that we need to do is to make the
non-process files in /proc symblinks to ../system/XXXX, and to do that
for a major rev or 2 of the kernel (time to let the 'legacy' stuff be
made obsolete by some other set of kernel changes).
Something for 2.3
--
Alain Williams
-
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/