Background:
The current kernel module system is quite bad. It lacks many of the 
features that are needed to do something useful with it.

Vision:
To add full functionality that makes it possible to have a complete
dynamic linked kernel. How this will work and its implications will be
described in a special paper.

Step one:
To add a real in-kernel symbol table handler that is useable at for
example crash dump debugging, inter-module references etc, and to 
have a real in-kernel linker that runs as its own thread and keeps
track of module references and related stuff.

Proposal:
We would like to check the symtab handler and the linker in as soon
as it is in suitable form. In step one, there will be no changes to the
user API the existing LKM system uses (e.g. if gurka.o is my old LKM
module, modload gurka.o will still work the same). The initial noticeable
benefits will be that it can handle symbol references between modules
and the ability to do post-mortem debugging of modules.
The linker can handle both ELF and a.out.
Principle of working:
- The linker runs as an in-kernel process
- Modload just tells the linker process what it should do, and the linker
  takes care of the rest like symbol table etc.
- The kernel symbol table is accessible via /dev/ksyms as well, so
  that userspace can make use of loaded symbols. (/dev/ksyms is in
  ELF format on all platforms)
- Everything in-kernel is handled as ELF, but the linker can understand
  both ELF and a.out.

I am in the process of putting together a paper describing how a complete
kernel module system should work, while still making use of the 
autoconfiguration functionality that is already included in NetBSD.
This will affect most parts of the system and needs to be thoroughly
discussed first, but to gain time (we have some spare time right now :-)
we think it's a good idea to start with the above.

-- Ragge