[lkml]   [1996]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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.


 \ /
  Last update: 2005-03-22 13:37    [W:0.185 / U:6.492 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site