Subject: Re: new sysctl(KERN_PROC, ...) interface (was: sysinfo(2))
To: None <firstname.lastname@example.org>
From: Aidan Cully <email@example.com>
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
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 = CTL_KERN;
mib = KERN_PROC2;
mib = KPROC_VERSION;
mib = op;
mib = arg;
mib = elemsize;
mib = elemcount;
and KPROC_VERSION get bumped when the structure changes in a way
incompatible with 'elemsize' compatibility.