[ On Friday, March 24, 2000 at 05:22:49 (-0800), Todd Whitesel wrote: ]
> Subject: Re: sysctl(2) and/or /kern for system variable manipulation
>
> Having dealt with programs that parse the output of GDB, and
> Hewlett-Packard emulators, I declare it categorically insane
> to base a long-term interface on something that prints human
> readable messages which are then parsed by programs.

That's because you were dealing with *unspecified* data formats.

> I am in favor of beefing up /kern, but it must be done in a
> machine-readable way; the current output of sysctl -a, or
> mixerctl/audioctl, is not too bad, actually. (See also environ(7).)

The issue is not between "human" and "machine" readability -- it is
simply one of ensuring the data formats are carefully and firmly
specified.  Why give up human readability when you don't have to!?!?!?
Providing for human readability of data has the advantage of almost
guaranteeing machine-independent data will stay that way too.

It should go without saying of course that ideally each structure should
be run-time extensible and/or versioned too so that issues with upgrades
are dealt with implicilty.

Indeed the concept of having so many namespaces in BSD is highly
questionable.  libkvm, sysctl, et al should all be moved to the
filesystem namespace.

As for whether or not this means duplicating the effort with maintaining
post-crash core dump analysis tools depends on how flexible those who
use such tools are willing to be.  If it is necessary to always
guarantee that 'ps -M /var/crash/*.0.core -N /var/crash/*.0' will
continue to work instead of having some new tool akin to the sysV
"crash" program (whether implemented as a separate tool or as a set of
GDB macros), well then yes, I guess it does mean duplicating some of the
maintenance headaches and bloating some programs.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>