On Thu, 10 Sep 1998, der Mouse wrote:

> 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's a non-searchable directory, a la ~ftp/private.
To look up a symbol, you just open /kern/kernelsymbols/the_symbol. If the
symbol's defined, you'll get a file which, when read, is the kmem address
of the symbol. If the sysmbol's not defined, you get a file not found
error. If the support's not built in, you don't get a /kern/kernelsymbols
directory.

This technique would work w/ net booted kernels, and a big advantage is
with lkm's. If lkm's are loaded, we really should be exporting their
symbols too. To do that w/ either the /netbsd route would be impossible I
think. Just passing the address out sounds much easier than messing with
faking an nlist which is then munged by a library in userland. 

If I understand things right, This in-kernel lookup wouldn't need many
more resources than lkms as all the symbols and symbol lookup has to be
there anyway.

This lookup could also be done through a sysctl.

Take care,

Bill