Subject: Re: Handling multiple lkm's
To: Todd Vierling <tv@pobox.com>
From: Darren Reed <darrenr@cyber.com.au>
List: tech-kern
Date: 09/16/1997 11:48:51
In some mail I received from Todd Vierling, sie wrote
> 
> On Mon, 15 Sep 1997, Chris G. Demetriou wrote:
> 
> : In my opinion, the 'right' thing to do is make all shared libs
> : effectively be dynamically loadable objects, in the dlopen()/.so
> : sense.  Then load them, and have a small dynamic linker in the kernel
> : (only #ifdef LKM!) which does the right things.
> 
> Uh-oh, I'm about to defend SVR4.  I'll go shoot myself now.  :)
> 
> Variants of SVR4 do exactly this, and go one step further:  the 'kernel
> symbol table' is not determined by the symbol table attached to the end of
> an a.out or elf file, but instead you _must_ call a syscall to ask for the
> address of a kernel symbol.  IMHO, this is a much "safer" way to do it, and
> is only a logical extension of using dlsym style LKMs.  If the mini runtime
> linker were to exist in the kernel, it should be trivial to create a syscall
> to find a kernel symbol.

Personally, I *really* like this feature of SVR4.  It makes debugging things
in the kernel when using LKM's so much easier.  The real trick, of course,
is to be able to rebuild the kernel after a reboot so that a useful vmunix.#
and vmcore.# are available.

Also, given the trend towards bloating kernels with everything under the
sun, I think the dynamic linking of kernel object modules is a cool idea
(and boy does the Linux implementation suck) - maybe even handling gzip'd
.o's with some external support(?).

Darren