Subject: Re: LKM diff for review
To: Jonathan Stone <jonathan@dsg.stanford.edu>
From: None <cube@cubidou.net>
List: tech-kern
Date: 10/25/2004 20:12:28
On Mon, Oct 25, 2004 at 11:01:09AM -0700, Jonathan Stone wrote:
> 
> Someone [not you?]  asked about long-term plans for LKM.

Quite possibly.

> I sometimes think about replacing LKM altogether: doing away with the
> userspace linker step, implmementing a minimal ELF linker/loader in
> the kernel, and hooking in modules via linker-set support, rather than
> the cumbersome ``module type'' described in lkm(4).
> 
> Getting rid of the userspace linker is a big, big plus for secure
> systems (where you don't *want* an executable userspace linker, for
> good and sufficient reasons).
> 
> Supporting boot-time load of kernel modules (a` la FreeBSD's .ko and
> bootloader) is another plus. (Not, I admit, for people who configure
> and build their own custom kernels; but for people who happily run
> with a GENERIC kernel, but who'd like a smaller footprint.)
> 
> (And even a nominal wave in the direction of source-code compabibility
> with FreeBSD-style kernel modules would be a plus, at least for me.)
> 
> Just thinking out load. Flames to /dev/null, constructive feedback welcome.

Well, I admit I've had a few ideas over the months, but never really got
around implementing them.

My thoughts were about some generic way to add code and data to the
kernel.  Here I'm not only thinking of ELF modules, but also, say,
firmwares for various devices (for example, ipw(4) can have different
firwares loaded).  An hypothetical ndis(4) would be a good candidate,
too, loading Windows what's-the-format-again binaries.

As for the ELF case, the one that probably matters most, my plan was
to stick with relocatable objects, and use link-sets for about every
meta data.  The point of that is the ability to merge modules, with
a longer term plan to ship a rather minimalist kernel and, maybe at
installation, maybe later, have the user merge his kernel with various
modules in order to get a final kernel.  Of course I'm far from that.

Having this ability would mitigate the need for a linker available
from the bootblocks.  You'd just prepare your kernel before booting.

I kept my mouth shut so far because I don't have code to show, but
maybe it is all the best if I get the flaming before actively working
on it.

Quentin Garnier.