Anders Magnusson <ragge@ludd.luth.se> writes:

> Ok: I sent a poll to Herb a couple of days ago about this, and he
> recommended me to send a note about it to tech-kern to get some
> feedback. I have planned to write a more extensive description of
> what we have, but I haven't had time yet. Anyway, here's essentially
> what this is about:
> 
>   We have at the company where I work changed the whole LKM system in NetBSD
>   to make it possible to work with a module-based OS. Much of this work
>   can be used in NetBSD and I have convinced the board to release it to
>   the NetBSD project, since it contains no intellectual property for us.
>   Anyway, it's a lots of changes, here's a few of them:
>   
> - 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.

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

>   
>   Those changes are more-or-less in a (for NetBSD) working state already,
>   among what is not done but will be fixed is:
> - Modload understands only a.out for the moment, but ELF support is on the way.
> - The devsw handler will also register devices for a devfs.
> - Modules will get a built-in relation system and revision info.
>   
> 
> This is basically what we have done/planned to do in the future. 
> We are using this code in production and will also be maintaining it
> because of that.
> 
> Ok, folks, comments to this?
> 
> -- Ragge