On Thu, Mar 11, 1999 at 07:58:49AM +0200, Jukka Marin wrote:
> 
> Use a "binary" format which contains N iterationss of "<TAG><LENGTH><DATA>".
> Here, <TAG> specifies the information type of <DATA> and <LENGTH> tells
> the length of the actual data <DATA>.  <DATA> may contain binary data
> such as integers or floating point numbers.
...
> No, this format would not be human readable because it would contain
> binary data - but it would be much faster to parse and it would still
> let different versions of kernels and userland binaries to operate
> as well as possible.

  I like it.  It sort of still has the problem of versionitis
-- there has to be a magic number for mem_used_bytes,
and mem_free_bytes, and mem_inactive_bytes, ...  I imagine that
header file will be quite large.  But it does provide slackness
w.r.t. new kernels.

  Another idea I was thinking about is, provide a
/kern/stats.binary that has the same values as /kern/stats, but
in binary, and with no names.  So, if /kern/stats held:
req_buff_size=8192
version=100000
...
mem_used_bytes=18375629
...

/kern/stats.binary would hold (in some sort of endianness):
00 00 20 00   00 01 86 a0   ...   01 18 63 cd   ...

  Applications would first parse /kern/stats, in order to figure
out the offsets for what they want, and then they would read in
all of /kern/stats.binary into buff[] in one fell swoop, and
grab out mem_used as buff[8], say.

  Or, we could mix this with your idea, and make the binary
format also contain a tag word for each data value.  ``Dumb''
applications that only need one or two values can simply scan the
/kern/stats.binary array for the hard-coded tag value;
``smart'' applications that need more or allow user-specified
strings can parse the verbose version to figure out the offsets
in the binary version; ``simple'' applications like shell
scripts or simple "grep mem_used_bytes /kern/stats" can use
just /kern/stats.

  The more I think about it, the more this last option appeals to
me.  The tag could also allow multiple tag words, by having a
flag set somewhere in the tag, and then we could even use the
sysctl numeric names for the values that have a sysctl
equivalent.  In the long run, this would provide a convenient
path to provide much sysctl functionality through the file
system*, and would provide motivation for extending the sysctl
hierarchy to contain more performance stats.

  Opinions?

  Brian

[*]  As mentioned earlier, we could also provide
/kern/sysctl/ddb/radix etc. for fine-grain per-variable access.
But in many ways, that's orthogonal to my original proposal, and
I don't think I could get that done for 1.4.