On Thu, 9 Jan 1997, Perry E. Metzger wrote:

> 
> Daniel Carosone writes:
> > But, it is the best way to keep out of the
> > kernel the greatest amount of the code which interprets the kernel
> > data structures and formats them for the user. If you consider the
> > interface to be the output of these programs, and that interface is
> > clean, then it can still be an aesthetically-pleasing solution.
> 
> CGD repeatedly points out another major reason for kmem groveling --
> so your tools can work on kernel core dumps.
> 
> I prefer file systems aesthetically, but CGD's argument is a bit of a
> showstopper.

Hmm. This thread is wandering into familiar ground. :-)

I agree that being able to look at a kernel core dump is good. I think
someone was working on a good solution; have kernfs export the kernel's
symbol table. Of course you have to have kernfs, and be keeping the symbol
table around, but libkvm could be taught to look for
/kern/the_symbol_table, and fall back on /netbsd if it's not there.

I think the problem I head was how to deal with lkm additions to the
table. Maybe make the exporting directory --x--x--x. You just attempt to
open a file named as the symbol (/kern/kernel_exports/cdevsw for example).
Just like in anonymous ftp in ~ftp/private, if you guess a good name, you
get a file. If not, you get a "file not found" error. The file you get
just contains the address of that variable, which you then use to grovel.

I guess my complaint with groveling through kmem is not doing it, but by
requiring the symbol table be in user space. If we're looking at the
running kernel, it knows best where its symbols are living.

Of course, if you don't want the bloat of this interface, you just don't
have ddb compiled in (which keeps the symbol table around as I understand
it), and you don't include kernfs. Then everything rolls back to /netbsd.

Take care,

Bill