> >   
> > - The symbol table handler (from DDB) is fixed to support the symtab from
> >   LKM's also. (Needed to have modules loaded on modules, and to get DDB
> >   to work on modules).
> > - Modload has got its own linker (no need for gld), and it has some small
> >   tricks to not page-align modules (saves LOTS of memory when there are
> Does this mean that you need to still know the name of the kernel that
> was loaded (/netbsd.old vs /netbsd).  Either the loader needs to be 
> in the kernel and/or have access to all (or some [the exportable]) symbols
> of the kernel.
The symbol/string table is read out of /dev/ksyms. The preferred way of 
how it should work is "/dev/ksyms || kvm.db || /netbsd || die". This makes
/dev/ksyms optional for people that does not want to have the symbol table
inside the kernel.
> 
> >   many modules). Also, modload loads the symbol table into the kernel.
> > - /dev/ksyms, to be able to access an up-to-date symbol table. (as a side
> >   effect ps stopped to care about from which kernel the system was loaded :-)
> > - Bdevsw/cdevsw is gone, instead there is a devsw handler to which
> >   device modules are registered/unregistered.
> There is an interesting issue here.  The old lkm scheme required that
> a module either a dev or a vfs or a single system call.  A much better
> design would let a module (a linkable unit) register as many and
> whatever services it needed to.  Coda for example had to abuse the scheme
> to be both a device and a vfs.
> 
We did not design any "magic" stuff to handle such things. Instead there
will be a register/unregister working way of modules. 
The module system (as we have planned so far) will also have relations
between modules and be loaded in something like a tree hierarchy.
This should interact in some way with the existing autoconf system,
how this will be done is still an open issue.

-- Ragge