Subject: Re: RFC: /kern/summary
To: Brian C. Grayson <email@example.com>
From: Jukka Marin <firstname.lastname@example.org>
Date: 03/11/1999 09:19:27
On Thu, Mar 11, 1999 at 01:09:25AM -0600, Brian C. Grayson wrote:
> 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.
> 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 ...
Well, how about adding the names in the tag system I suggested.. the name
length would also be specified as one field, so the name could easily be
skipped. Actually, it might be faster to have a total length of one entry
in one field so the entry could be easily skipped..
I think the tag list device is all that is needed. If one wants to print
out a human readable version, all that is needed is one simple userland
binary which parses the tags and prints out the names and values it finds.
If the names are included in the taglist, this is simple and the userland
binary needs no knowledge of the kernel internals.
Also, a simple userland binary could be used to extract information in
> 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.
No need to be that complex :-)