Anders Magnusson wrote:
> 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.

YES YES YES!

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

Mmmm, I missed this quite a bit ocassionally and had to resolt
to statically compiled kernels when I REALLY needed it.

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

Mmmmm, great! Less /dev/kmem grovellers!

Having the linker as in-kernel process would also make it possible (besides
other neat things) to allow modload on higher securelevel. Since
modload would always upload only "raw" mod.o file, it's possible
to register "safe" lkms and allow to load only those later on.

I'll gladly help with this, if you would need one more coder :)

Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>      http://www.ics.muni.cz/~dolecek/
@@@@  Wanna a real operating system ? Go and get NetBSD, damn!  @@@@