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
"control" meaning.


> 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

-- 
Hubert Feyrer <hubert.feyrer@rz.uni-regensburg.de>