Subject: Re: LKMs (was Re: IPSEC in GENERIC)
To: Steven M. Bellovin <smb@cs.columbia.edu>
From: Garrett D'Amore <garrett_damore@tadpole.com>
List: tech-kern
Date: 02/20/2006 09:06:03
Steven M. Bellovin wrote:
> In message <43F9F1C0.7040100@netphreax.net>, "Thomas E. Spanjaard" writes:
>
>   
>> If this happens, I'd like to go the whole nine yards and put all this in 
>> separate VM spaces. In other words, go the microkernel way, as that's 
>> where this is headed. Any objections regarding performance loss, well, 
>> look at L4. If the kernel itself (and VMM) go in *that* direction, 
>>     
> performance will be of no issue (or even more academic, put everything 
>   
>> in the same VM space, but limit the memory mappings processes/modules 
>> have, and not have to worry about many heavy context switches). Of 
>> course, this is a very long way to go, and I doubt if many like it.
>>
>>     
> That's a much larger arechitectural change, and I think there are 
> serious performance questions.  It would be nice, but I don't think it
> will work well enough.  That said, there's only one way to find out...
> (Personally, I don't think there's that much benefit to NetBSD from 
> doing that for device drivers.  File systems, on the other hand...)
>
> 		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
>
>   
I hear a master's thesis in there somewhere. :-)  Too bad I don't need one.

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

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191