Subject: Re: RFC: /kern/summary
To: Julian Assange <firstname.lastname@example.org>
From: Hubert Feyrer <email@example.com>
Date: 03/10/1999 13:12:31
On 10 Mar 1999, Julian Assange wrote:
> (1) are we trying to produce somethign that is human readable or
> computer readable? There seems to be a conflict of goals here.
Um, why? The proposed "key=value+ format seems to fit both quite well.
And from previous discussion i think to recall that returning binary
structures (for better machine readability) is not a real benefit given
that we have all sorts of string parsing functions available.
> (3) scanf and open etc are slow. look how slow top / ps is under linux,
> further there is no random access to the information. you have
> to read it all even if you only want a part.
That's how current /proc is too, so no big loss here.
> (5) you have to create new ascii standards for representation of
> non-trivial data types. e.g arrays, linked lists, trees,
> flags etc, code to generate AND parse it.
um, the original proposal didn't include too many explicit symbols to be
incldued in that /kern/stats file, but I don't think that anything
tree-like or so will be shown there. Other ways to display this can be
chosen, look e.g. at the process tree (which can be displayed by pid and
ppid - see pkgsrc/sysutils/xps btw :-).
> (6) access to variables is split between the sysctl and and the
> /kern framework. doubling the amount of work involved if you
> want a variable in both.
um, a status value is one thin, a "control" value (sysCTL) is something
different. I wouldn't expect the ammount of free memory to have some
> I think you would be far better off transmuting kernfs into an
> accurate representation of the sysctl namespace. you could even
> have a ".all" file at each level in the hierarchy which would
> represent all information at nodes under it. i.e ".all" in the
> root would be equivalent to sysctl -a. this would take advantage
> of the large existing sysctl namespace, and build upon it,
> making both sysctl and kernfs stronger.
Not a bad idea either... Maybe we should
- make a list of all variables we want to have accessible somehow (r/w):
- decide where to put them and how to access them:
I think we should agree on how to make which information available first,
though I wouldn't mind having everything in /kern and /proc. :)
Hubert Feyrer <firstname.lastname@example.org>