On Fri, Apr 07, 2000 at 11:40:04PM -0500, erh@nimenees.com wrote:
> On Fri, Apr 07, 2000 at 12:05:17PM -0400, Aidan Cully wrote:
> > I've been thinking for a while about a 'sysinfo' syscall, which would
> > behave quite a bit like using sysctl() to read values from the kernel,
> > but with the addition of a 'flags/flaglen' argument pair for allowing
> > the kernel to do a lot of the filtering on the data before it goes to
> > userland...  I haven't done anything with it, because I couldn't think
> > of any major advantages of it over using sysctl().  Maybe it would be
> > well suited to this function, though?
> 	Well, it looks like sysinfo() changes void *newp from sysctl() to
> something with a more defined structure instead of each sysctl for itself.
> What kind of filtering would this enable you to do?

I was thinking of it in vague terms of 'each sysinfo for itself', with
the filtering was in the 'flags/flaglen' parameter pair.  They were
meant to be completely optional, and would be used to strip a lot of
the data out of what sysinfo() would ordinarily return...  I thought of
sysinfo() as a way to access entire tables of kernel data, like the
process table, network interface table, and with the ident discussion,
the open connection table.

> > I was thinking about it as a general replacement for anything that used
> > libkvm against a live kernel.  Most of the motivation was in those
> > periodic 'proc size mismatch'es that /bin/ps gives when upgrading the
> > kernel, but done a bit differently sysctl() could avoid those as well.
> 	I thought this was from the struct proc changing when upgrading
> the kernel?  Wouldn't the solution to this be to define struct kinfo_proc
> not in terms of a struct proc but with a standardized proc-like structure?
> Then perhaps also have a separate sysctl to get the full info.

Well, yes...  I wrote down the approach I was going to take to
get around this...  Note that sysctl() can use this, too:

It's possible that sysinfo_proc might have members added/removed,
just as struct proc has, but this shouldn't break binary
compatibility, because any time the definition of
struct sysinfo_proc changes, the value of the SIKP_TABLE constant
would be changed, and compatibility code in the kernel would be
able to return proc_table structures related to both SIKP_TABLE
constants.  The hope is that this interface is generic enough that
*any* userland program which uses libkvm will be able to get the
info it needs (and, within reason, *only* the info it needs)
through this interface.

I believe the approach is very similar to the way we handle
compatibility syscalls.

> 	Another neat thing would be, when handed a NULL oldp, for the
> KERN_PROC sysctl to allocate the space to build the array of kinfo_proc
> itself and save it.  Then, when the next KERN_PROC call, with an oldp,
> comes in it returns the saved info.  Another NULL oldp request from the
> same process would replace the previous info and a timeout could handle
> reclaiming the space if the process never retrieved it.

I haven't thought about that at all...  That could be pretty neato.

--aidan