der Mouse writes:

> 
> >> Well, yeah.  My point is that for /kern/kernel to be useful, it has
> >> to provide a symbol table for nlist() to use, and for that, it needs
> >> to have the symbols available to it in the first place.
> 
> > My thought is we should do something slightly different.  Rather than
> > try to point to the loaded kernel, why don't we just have something
> > like /kern/kernelsymbols.  [...]
> 
> It doesn't matter how the kernel exports them, as a symbol table
> suitable for nlist, as a kernelsymbols directory, whatever, it has to
> have them available.  They aren't always.  (Though admittedly, provided
> userland fails over to using nlist on /netbsd, none of the ideas would
> make things any worse than they are now.)

I hate the idea of the kernel doing big lookups, or requiring huge
lookup tables for the symbols.

I do like the idea of the kernel being able to tell userland about its
symbols though.  /kern/kernelsymbols seems like a nice way to
implement it.  I think a pragmatic solution is to implement
/kern/kernelsymbols, but to not be capable of resolving absolutely
every global symbol (unless it's convenient), just the ones known to
be required by various utilities.  If the kernel doesn't know,
userland can fall back to /`sysctl -n kern.booted_kernel`.

This would please most of the utilities most of the time, and the
kernel image need not even be available (net boot) to use the standard
kmem trolling netbsd utilities (and perhaps any in the packages, like
top).

(I did also think of maybe a userland daemon that could resolve
unknown symbols for the kernel from the kernel file if known,
subsequentially cached by the kernel, but I think maybe that would be
a mistake. :)