Darren Reed wrote:

> In some email I received from Hubert Feyrer, sie wrote:
> > On Fri, 16 Jun 2000, Simon Burge wrote:
> > > For vmstat (& iostat) we need the values of tk_nin and tk_nout.  Related
> > > values (but not used at the moment) are tk_cancc and tk_rawcc.  Would it
> > > be better to retrieve a single "struct tkstats" that contained all four
> > > members or add a new node and retrieve kern.tkstat.{tk_nin,...} with
> > > separate sysctl calls?
> > 
> > If we'd ever get a sysctlfs, the latter may be better for human
> > readability.

Good point.

> I've been giving the compat32 issue some thought...it's really not at all
> well suited to dealing with in any elegant way except from doing things
> MIB style.

True - it's a tad ugly to use fixed size types for compat32 safeness,
but it's not that bad.  If we were go completely simple-type MIB-based
for everything, wouldn't this also require fixed size types for the MIB
entries, or would that be somehow returned (eg, you say to the kernel "I
want kern.proc.1234.vm.rss", and it says "that's a u_int32_t with the
value of ...")?

Also, there would probably have to be a way to return multiple MIB
entries with one call - image the overhead for ps (for example) if each
field for each process had to be retrieved with individual syscalls
(that's 11 x 137 just for the data retrieval plus a few to get numbers
on my home box right now, vs 2 + 137 with the current sysctl method
(including one each for each argv string)).

> Is it worth punting on compat32 and mib support until we have
> something like sysctlfs ?

Personally, I think a (elegant) sysctlbyname() is more important
than a sysctlfs.

Simon.