On Wed, Mar 10, 1999 at 03:50:09PM +0100, Soren S. Jorvang wrote:
> 
> [Warning: I am not too happy about things like /kern and /proc in
> general.]

  I know a bunch of people don't seem to like /kern and /proc.  :)
Are there any logical reasons for this?

  I know one reason to not bother mounting them is because
"there's nothing useful you can do with them that you can't do
other ways."  But that won't be true for long:
My modified ps, for example, provides useful functionality that
currently can _only_ be provided through /proc -- it works (in a
limited fashion*) even when you boot with an older or newer
kernel than the version of libkvm with which ps was built.

  Yes, some Linux /proc based stuff is slow.  But We're Not
Linux.  I've already come up with two different methods to make a
pure-/proc-based ps require only a handful of syscalls for both
the most common usages and the general case (Linux' version
requires O(# active processes) syscalls for every use).

> I think the variables that Brian suggests adding to kernfs
> would fit in well as sysctls.

  Doesn't each sysctl take a syscall?  xosview would then require
30x more syscalls using sysctl than using /kern/stats.  Yes,
these stats probably ought to be accessible via sysctl, and I
will probably endeavor to help out with that effort, but I
don't think that sysctl is the most efficient or most
user-friendly method for providing these stats for _every_
application that wants them.

> What I'd really, really like to see is a getprocent(2) (or something
> like that) syscall. I imagine it returning a generalized proc structure
> and the pid of the next process in the list. Or perhaps all processes
> in one 

  I plan on providing this -- all processes in a single system
call -- through some modifications to /proc.  But that's a
different problem, for a different day.

[*]  The only reason my /proc-fallback ps doesn't provide full
functionality is because the /proc file system does not provide
sufficient information.  That is yet-another-problem that I plan
on attacking.

  Brian