Messages in this thread | | | Date | Tue, 11 Jun 1996 09:43:02 +0300 (EET DST) | From | Linus Torvalds <> | Subject | Re: rationale behind /proc filesystem? (wuz Re: 2.0, loggings....) |
| |
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
| |