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.
Regards,
Tigran
On 2 Dec 1998, Mirian Crzig Lennox wrote:
> Greetings all.
>
> I've been lurking on the list for a while, and thought I'd introduce
> myself with a question. I'm a BSD hacker since the 80s, but I'm
> assured by my Linux friends that this won't be held against me, so
> long as I'm not obnoxious about it. :)
>
> Anyway, the question I have is this: I would like to work on splitting
> /proc into /proc and /kern, such that /proc is only for process
> information and /kern is for kernel structures. Not only will this be
> more elegant and less cluttered, but it will give proc and kern their
> own separate pools of inodes.
>
> 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.
>
> Another thought I had is to make the pseudo files in /proc and /kern
> display real size information instead of 0, as they do under BSD,
> since I often find it's useful to know roughly how much virtual
> information is "contained" in those files without actually having to
> look at the contents or pipe the contents through a program.
>
> What do people thing about these ideas? Is there thought to be any
> merit in them?
>
> --
> Mirian Crzig Lennox Systems Anarchist
> "There's a New World Order coming every minute.
> Make mine extra cheese."
>
> -
> 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/
>
-
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/