Subject: Re: RFC: /kern/summary
To: Jukka Marin <email@example.com>
From: Brian C. Grayson <firstname.lastname@example.org>
Date: 03/11/1999 01:09:25
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:
/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, 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
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.
[*] 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.