Subject: Re: sysinfo(2)
To: None <email@example.com>
From: Aidan Cully <firstname.lastname@example.org>
Date: 04/08/2000 02:27:50
On Fri, Apr 07, 2000 at 11:40:04PM -0500, email@example.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
> 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.