>>>>> On Sat, 7 Oct 1995, "Neil J. McRae" <neil@demon.net> writes:

> Why would I want to use kernfs/procfs?


At this point both kernfs and procfs are sort of "demonstration projects" 
that represent nifty ideas, but are not used by any other parts of the 
system.  As such, there's not much of a convincing argument for putting 
either in your kernel.  On the other hand, neither takes up a whole lot of 
kernel text or data space, so it's really your call.

Procfs was designed as a replacement for ptrace() in writing debuggers.  I 
don't think the NetBSD gdb currently uses procfs, however.  Procfs could 
also be used by ps.  I don't have any measurements as to which interface 
would make a faster ps, but I could imagine arguments for either side.  
Also, if you had an application which just needed to read from the VM space 
of another process, procfs might be very useful to you.  

The story for kernfs is similar.  Nothing uses the interfaces exported by 
kernfs.  An example of such an interface is the loadavg.  Instead of uptime 
or xload (e.g.) requiring -lkvm, they could just open "/kern/loadavg" and 
re-read that file to get current load info.  This would be a big win in 
terms of code not breaking when you boot from a non-default kernel and/or 
when big changes in the kernel or libkvm take place.  In addition, these 
programs would no longer require special permissions to run.  Also, kernfs 
could be used for more interesting stuff, like getting info about 
installed/configured devices (see recent thread on -current mailing list), 
or getting info about memory stats.  Currently, nothing in the system uses 
any kernfs interfaces, and so there is no real incentive for you to include 
this in your kernel.  

It seems to me there's a sort of chicken-and-egg problem.  If one could 
count on kernfs or procfs being present, certain utilities would become 
simpler.  But since one can't rely on them, the utilities are written more 
generally.  Because no utilities require kernfs or procfs, there's little 
incentive for people to include them.  Therefore, one can't rely on either 
being present, and so forth... 


Hope that's helpful,

Tom Pavel

Stanford Linear Accelerator Center
pavel@slac.stanford.edu                 http://www.slac.stanford.edu/~pavel/