Date:        Mon, 20 Nov 2000 18:00:05 +1100
    From:        Simon Burge <simonb@wasabisystems.com>
    Message-ID:  <20001120070006.1DC7D1FF85@thoreau.thistledown.com.au>

Don't take anything I say as pertaining to sysctl in particular,
this is more just about mib's in general...

  | There's also the calling conventions from userland.  For the above example,
  | this would be:
  | 
  | 	mib[0] = CTL_KERN;
  | 	mib[1] = KERN_EVCNT;
  | 	mib[2] = elem_size;
  | 	mib[3] = elem_count;	/* unnecessary?  we already have oldlen */
  | 	sysctl(mib, 4, ...);
  | 
  | I'm not sure that overloading the last mib position(s) is the cleanest
  | way of passing elem_{size,count} but can't think of any better way of
  | doing it.

For a traditional MIB, once KERN_EVCNT is assigned a numeric value,
the structure returned is fixed forever - if new elements are added,
old ones removed, the order changed, or anything else weird like that,
a new number needs to be assigned.

That is, the size is implicit in the OID, it should never need to be
made explicit.

It isn't as though OID values are a scarce resource that they need to
be conserved...

Again, I know nothing about how sysctl works, but I would have thought
the same general kind of interface would be applicable - userland will
use whatever value for KERN_EVCNT is persent in the include files when
it is compiled (and consequently get the corresponding struct definition).
In the kernel, all versions back however far into eternity binary
compatability is to be retained would be supported as different nodes
on the tree (which is more or less what you would need to do with the
explicit size ... except that just an explicit size doesn't help if
you delete an int and add two shorts to the struct - the size stays
the same in that case (well, making come compiler assumptions it does))

kre