Messages in this thread |  | | | Date | Thu, 3 Dec 1998 21:39:10 +0000 | | From | Alain Williams <> | | Subject | Re: /proc and /kern |
| |
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/
|  |