Date: Sat, 9 Sep 2006 15:36:58 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Howard Su <howard0su@gmail.com> Cc: arch@freebsd.org Subject: Re: Modularize kernel Message-ID: <20060909153205.G87517@fledge.watson.org> In-Reply-To: <f126fae00609090712u53a075cai87fe9812d63fdc1a@mail.gmail.com> References: <f126fae00609062247n62aaf3d7tac8f3980eeb148fb@mail.gmail.com> <20060907.153239.1219861549.imp@bsdimp.com> <f126fae00609071949u79960am7d781b3fca8058b8@mail.gmail.com> <20060908.001045.1683322424.imp@bsdimp.com> <20060909131907.G84834@fledge.watson.org> <f126fae00609090712u53a075cai87fe9812d63fdc1a@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 9 Sep 2006, Howard Su wrote: > On 9/9/06, Robert Watson <rwatson@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060909153205.G87517>