> 
> > SYMTAB_SPACE is retained as-is; this will change to another way
> > of loading the initial symbol table in the future.
> 
> Well... Normally, a boot loader would load the initial symbol table for 
> the kernel.  SYMTAB_SPACE is used on systems where that is not possible 
> (e.g. kernel booting directly out of flash, or dumb firmware on some 
> eval boards which can't support boot loaders).
> 
Yep, so I thought it would be cleaner solution if it could be loaded
after the kernel starts, by for example "cat /netbsd > /dev/ksyms" to
get the master table.  That would replace SYMTAB_SPACE.

> > The kvm and libc nlist routines are not fixed here. There are a bunch 
> > of
> > more changes that must be done for them to work; they use mmap() to 
> > read
> > the symbols of a file, which cannot be used.  The same is true for 
> > kvm_mkdb,
> > but it is questionable if it should be around; creating a static db for
> > kernel symbols that may move around is not necessary a good idea.
> 
> Hm... Not possible to play a trick with mmap in the /dev/ksyms driver 
> to make it work?
> 
The problem is that for modules then the symbol table and the string
table would need to be on (at least) two extra pages for each module,
which would require a large amount of extra memory if there are say,
50 modules.  Maybe it's not a big problem on newer machines, but older
would loose much of their memory.

> Regarding kvm_mkdb(8), I still think it's useful to have that; it makes 
> nlist(3) a lot faster (or, at least, it's supposed to).  Maybe you can 
> add support for poll(2)/kqueue(2) on /dev/ksyms, and some persistent 
> daemon can keep the db up to date?
> 
That would be doable, yes.  Another way is to make nlist use the 
ioctl's that are currently disabled that do the lookup in-kernel.
That would be as fast.

-- Ragge