On Sun, 10 Nov 1996, Jason Thorpe wrote:

> On Sun, 10 Nov 1996 18:37:21 -0800 (PST) 
>  Curt Sampson <cjs@portal.ca> wrote:
> 
[snip to comment about not giving up kernel post-mortems]
> I'm not sure of the value of this... It's nothing different than
> what the kmem interface would give you...

My complaint with the current kmem interface is not about what it will
provide or how. but it reliance on /netbsd. The silly kernel knows where
it's hiding all these variables, why can't it tell userland?

>  > > 	(a) In order to use them, it requires people to load up
>  > > 	    their kernels with kernfs and procfs.  This is bad,
>  > > 	    particularly in an "embedded" application.  For example,
>  > > 	    we have a couple of NetBSD IPv6 routers here, and the
>  > > 	    kernels are lean, but being able to use iostat and
>  > > 	    vmstat is good.
>  > 
>  > Would it bloat terribly if we included the ability to do both in
>  > these utilities (or #ifdef'd them)? I'm sure that there are people
>  > out there regularly recompiling kernels that don't have the time
>  > and space to do the whole userland too who would be happy to have
>  > a userland that didn't need updates so often.
> 
> Well... let's think about this for a sec...
> 
> If you're reading actual structs and whatnot from /kern or /proc,
> you have the exact same problem as if you'd used kmem, because
> the format of a structure may change...

True, but you always have that problem. My experience (which might not
match everyone elses, I'll admit) is that I'm often hacking on the kernel
to do one thing or another. I don't often change the internal structures,
just where they live.

For my work pattern, a libkvm that could look at /kern/ksymbol (or some
similar file) for a symbol table, and roll back to /netbsd if that fails
would be great, and a small change. If you don't like kernfs, this
library's fine. If you do, this library's fine. For a static instalation,
you just keep /netbsd correct, and all is well. For a more dynamic
instatation, just add kernfs.

I thought someone had started on getting kernfs to export the symbol
table?

> If you read strings from multiple files, then you've:
> 
> 	- added complexity to the program that needs the data,
> 
> 	- made the program that needs the data much slower than
> 	  it needs to be.
> 
> In short, you don't gain anything; in fact you lose.

I guess it'd depend on the use for the results. If they are going to go
to and then back from ascii, you're right that we loose. If, however, the
idea's to let the (super?)user cat a file to learn something, then if
adding code to kernfs to monitor the variable is simple; just one more
line in the switch table. It could well be that this code's smaller than
adding a program and manpage to grovel in the kernel. True, you have to
have kernfs to get this savings, but once you've got kernfs, multiple
variables can be exported easily.

I think kernfs/procfs will work better in certain situations, and libkvm &
friends in others. I think NetBSD will be best served if we balance the
two possabilities.

Take care,

Bill