Modularize kernel

[Robert Watson]

On Sat, 9 Sep 2006, Howard Su wrote:

> On 9/9/06, Robert Watson <rwatson at freebsd.org> wrote:
>> 
>> On Fri, 8 Sep 2006, M. Warner Losh wrote:
>>
>> One of the biggest concerns I have with moving towards a heavily 
>> modularized default kernel is that we may find we need to explore improving 
>> our automatic loading of modules.  For example, if we want to de-populate 
>> the base kernel with respect to device drivers, which take up quite a lot 
>> of space, we'll want to look both at how to handle early boot, and later 
>> loading if hardware turns up -- issues we've largely avoided by virtue of 
>> compiling them in.  We may, for example, want to look at Apple's approach 
>> of loading all the available modules sequentially early in the boot to see 
>> what attachs, unload the idle modules, and then provide demand loading 
>> later.
>
> How about you can add one entry into TODO list with some clarification to 
> encourage some volunteers to work on it.

I think that coming up with a more clear tasking is important before this go 
on the todo list.  I've noticed that often patches turn up for TODO list items 
that capture the literal intent of the item, but sometimes not the spirit, 
which has the effect of discouraging everyone involved when it doesn't get 
quickly committed, and/or requires significant reworking.  There are some 
tricky architectural issues here precisely because we presumably want to end 
up with something fairly clean and intuitive, rather than something baroque 
and obscure.  If we get this wrong, we make life harder for everyone. :-)

I'm not sure I have a clear understanding of the requirements from the device 
driver side -- on the general service side, it's fairly straight forward 
because you simply say "If you want this service, load this module", or in the 
case of management tools, the module is loaded on demand by the management 
tool.  This works well because the model is basically driven from user space 
already.  The driver problem is trickier because it interacts with the early 
boot, before there is a user space, because it's driven by hardware-originated 
events, and because the model for determing what module to load isn't 
well-defined in the general case.  Apple has a model that stores device 
information in parseable XML associated with the driver, which helps their 
kext management daemon decide what to load in order to attach a recently 
discovered device.  They also have a module reference count model that allows 
them to easily load a pile of drivers, then tell all the ones that never 
attached to anything to unload.  Perhaps Warner and others can speak more to 
whether something like this makes sense for us, or how similar notions might 
map into what we have today.

Robert N M Watson
Computer Laboratory
University of Cambridge