Subject: Re: new sysctl(KERN_PROC, ...) interface (was: sysinfo(2))
To: None <>
From: Aidan Cully <>
List: tech-kern
Date: 04/15/2000 15:27:17
Simon Burge wrote:
> The new KERN_PROC2 handler would stuff a relatively fixed size struct
> kinfo_proc2, with any new elements only ever being added to the end of
> the structure.  kvm_getproc2() would also grovel a memory image and fill
> it in so the programs using the new interface will still work on crash
> dumps.

Hmm...  The main reason behind the KERN_PROC2 interface is to provide
binary compatibility in the face of changing sizes of kernel structures.
How can you provide this compatibility in a userland function operating
against a dead kernel, that doesn't know (does it want to know?)
anything at all about the size and layout of internal kernel structures?

> Any basic flaws in this line of reasoning so far?  Aidan - I know this
> is not exactly what you had in mind; how much different is it?

Since you asked... :-)
There are really just two significant differences between this and the
interface I had in mind, that I can see...  The first is that the
versioning is provided by the 'elemsize' element of the mib, instead
of by the KERN_PROC2 constant.  The second is that there is no 'flag/
flaglen' argument pair, for letting the kernel play a bigger role in
filtering out which processes to show the user.

After thinking a bit more about the versioning, I think a hybrid
approach is best:  When elements are removed from the structure, or
change sizes, or get re-sorted, bump the KERN_PROC2 constant and
provide a compatibility function[*].  But also provide the 'elemsize'
argument, for dealing with adding fields to the structure.  Best of
both worlds, right?  The 'flag/flaglen' thing, I don't care about.

There's one other difference, which is that you're working within
sysctl(), and I suggested a new 'sysinfo()' syscall, instead...  The
thought was that, to the best of my knowledge, sysctl() wasn't
originally meant to be a way to pull large amounts of read-only data
from the kernel, so a new interface better suited to it might be
better.  Again, though, probably not worth arguing about.

*: I should probably be clearer, here.  What I mean to say, is
KERN_PROC2 should stay the same, and the mib have another element
after it always initialized to KPROC_VERSION (or something)...
mib[0] = CTL_KERN;
mib[1] = KERN_PROC2;
mib[3] = op;
mib[4] = arg;
mib[5] = elemsize;
mib[6] = elemcount;
and KPROC_VERSION get bumped when the structure changes in a way
incompatible with 'elemsize' compatibility.