Subject: Re: lkm improvements ...
To: Robert V. Baron <email@example.com>
From: Anders Magnusson <firstname.lastname@example.org>
Date: 01/24/1999 22:09:23
> > - 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.