Re: rationale behind /proc filesystem? (wuz Re: 2.0, loggings....)

Linus Torvalds (torvalds@cs.helsinki.fi)
Tue, 11 Jun 1996 09:43:02 +0300 (EET DST)


On Mon, 10 Jun 1996, Hasdi R Hashim wrote:
>
> This is one thing I STILL don't get about /proc filesystem. Just adding
> one simple swiss-army kind of syscall should give you all the information
> you need about the kernel without even checking the /proc filesystem. A
> syscall implementation is a lot smaller /proc and more efficient (all that
> open/read/write/close stuff - yuk!)
>
> What is the rationale behind /proc filesystem? Is this part of making
> almost everything in UNIX look like a file? From my understanding, the aim
> of /proc filesystem is enable programs like ps to check on the system
> status without poking to version/config specific part of the kernel (did I
> get that right?). Why not add a syscall? Can somebody explain this me? :}

What does a syscall buy you in a perl script?

How do you handle "new" things gracefully with a syscall?

How do you handle dynamic things gracefully with a syscall?

In short, there are several things going for the /proc implementation:
- you can use _generic_ tools on it (not just perl, although perl is
obviously a good tool)
- it has a very obvious extension mechanism
- it has built-in name services (using the normal UNIX name service: the
filesystem structure). Think of the /proc filesystem like the "DNS"
for kernel information..

A system call is faster, agreed. And if there are _real_ problems with
the /proc approach, and there is something performance-critical that
needs some specific information, we'll add a system call for it. But
system calls are a lot harder to make dynamic, and if you try you'd
probably end up doing what /proc already does.

Linus