>> 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.)

> This technique [has] a big advantage [] with lkm's.  If lkm's are
> loaded, we really should be exporting their symbols too.

Depends on what you're doing with the symbols.  As simple examples each
way, kvm_mkdb doesn't need them and probably doesn't want them; gdb -k
(whatever we're calling it nowadays) does.

> To do that w/ either the /netbsd route would be impossible I think.

Yes, the methods that end up merely allowing userland to locate the
booted kernel file (symlink, sysctl, whatever) do have the disadvantage
that the kernel can't dynamically change the exported symbols on the
fly.

> Just passing the address out sounds much easier than messing with
> faking an nlist which is then munged by a library in userland.

Depends on your point of view.  It's *more* trouble for userland, since
userland has to be prepared to handle nlist() anyway, so the easiest
thing there is just to sic nlist() on a different file.  I'm not
convinced the code to fake a symbol table in an executable file isn't
going to be smaller and/or less complicated than the code to implement
your /kern/kernelsymbols.

> This lookup could also be done through a sysctl.

How?  AFAIK there's no way to represent the (string) symbol name in a
sysctl MIB (short of something really ugly like overlaying the string
onto some of the MIB values).

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B