Subject: Re: ksyms patches.
To: Jason Thorpe <>
From: None <>
List: tech-kern
Date: 04/21/2003 17:32:27
> > 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