On Feb 20, 2006, at 9:14 AM, Thor Lancelot Simon wrote:

> On Mon, Feb 20, 2006 at 09:06:03AM -0800, Garrett D'Amore wrote:
>>
>> Anyway, I generally concur with Steven, I'd rather get to basic  
>> LKMs now
>> and not get bogged down by over-engineering the project.  The real
>> question is: does core@ agree, or are there still serious  
>> objections to
>> LKMs in principle.  (It seems like the performance question is mostly
>> answered, though some actual benchmarking would be useful.  Can't do
>> that without actually implementing more LKMs though.)
>
> What's really needed is an in-kernel loader.  At least two developers
> have stepped up in the past and claimed to be in the midst of writing
> one of those, but nothing's ever come of it.
>
> I also question whether, without versioning of modules and without
> inter-library dependencies, this will actually ever be particularly
> useful.  Finally, I think it's important to retain the ability to
> build a monolithic kernel for applications where the entire blob
> must be verified -- *without* running a chain of dependencies and
> hoping you got it right.

The one mistake I think we have is that LKM's are special.  IMO, there
should be nothing special about a LKM.  It should use the exact same
services to make itself to the kernel as a static module built into a
monolithic kernel.

A module should have one entry point.  However, the use of link sets
complicates things.  We need a common routine to do link set processing
for the various types of link sets.