> I remember you've anready brought this up at one occasion.
> It's elegant, and it would make LKMs more save and secure.
> But perhaps the code which does the real linking can still be
> outside the kernel, with some access to the kernel's address
> space.
> Do you know how DEC's /sbin/loader works?

/sbin/loader is the RTLD-equivalent.  Yes, I know more or less how it
works (because I read the paper from OSF which describes how the OSF
loader works, and the DEC OSF1/Digital UNIX /sbin/loader seems to be
derived fro mthat).

As far as I can tell, it's completely orthogonal to loadable kernel
modules, and the relevant manual pages seem to agree on this.


That having been said: Why put the "code which does the real linking"
outside the kernel?  The "average" a.out shared loader seems to be
about 65k text + data (OK, OK, average of the i386 and arm32 shared
loaders 8-).  A fair chunk of that is code which isn't needed in the
kernel: dl*() implementations, code to handle basic dynamic linker
startup, etc.  I think it's quite reasonable to say "if you want LKM
functionality, you have to pay 50k for a loader in your kernel."
(Note that the rest of the LKM machinery -- much more is needed than
is there now, for a good implementation -- will cost something more,
as well.)  Theoretically, the benefits of a complete LKM
implementation would outweigh that (by a lot), anyway, right?  8-)

Also, if you do the actual linking outside the kernel, then you
sacrifice what security you can have by doing it inside the kernel.



chris