Date: Tue, 29 Dec 1998 14:42:26 +0800 From: Peter Wemm <peter@netplex.com.au> To: Warner Losh <imp@village.org> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: kld and on demand device loading Message-ID: <199812290642.OAA71584@spinner.netplex.com.au> In-Reply-To: Your message of "Mon, 28 Dec 1998 22:54:02 MST." <199812290554.WAA23027@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh wrote: > > I've been kicking around ideas for making kld even more useful than > I'm currently finding it. Before getting too deeply into the kicking > around, I thought I'd define the problem and see if others have > thought about it as well. > > Once upon a time, I recall that the linux kernel had a way to > dynamically load drivers and unload them on an as needed basis. Need > to make a slip connection, the slip driver would load. Once it was > done it would unload. > > In the long term, I'd love to see something like that. I believe that > it dovetails well with the new-bus project nicely. In the near term, > an area that it fits fairly well is the pcmica stuff. When a card is > inserted, the module is loaded, and when removed it is released. I > was thinking of hacking pccardd to do this, but then got to thinking > better of it and thought I'd ask for people's input before jumping > into that. The way I imagined this sort of thing would work, would be that there would be some sort of demand-loading shim that can be configured in place of the driver in question. Trying to configure this sort of thing with the present config(8) would be fun though :-) - unless the default is demand loading if the driver isn't present (which I think would get more than a few objections). Also worth considering.. I've seen several references to different methods of autoconfiguring modules. One is to have the loader read the bios tables and load what is known to be needed as well as any isa devices that were requested. I could imagine that drivers could aquire a loader-callable probe interface so the individual modules could probe before the kernel proper is started, but I suspect that way leads to madness. The other way is to cheat a little and use the bios tables as hints for what the loader should preload, and let the kernel itself figure out what to do later. One other point, the present inuse-count mechanism is inadequate for doing this. Apon unload, the modules are told "unload time!" and are (I think) given a veto. However, with a kld module having several internal modules (eg: coda has a vfs and a devsw module), and they could have different inuse status. The vfs may be willing to unload, but the devsw module may not.. It's too late to get the vfs module back after it's already been told to shoot itself and the cdevsw module says "no, wait...". We need to be able to reclaim the pages freed up by unloading preloaded modules, there is no mechanism for that yet. (the solution seems overly complex given the present distinct pv_entry tables and the vm_page_t tables that (mostly) shadow each other and a phys_avail[] array is used to coordinate them. What I want to try some day is to make a small md_page struct that is inserted into the tail of the vm_page_t and replaces the pv_entry shadow. This can be done in an arch neutral way. Then a vm_page_t can be quickly "found" from the md_page and vice versa without having pointers to each other or doing array offset arithmatic. phys_avail[] could mostly go away then, and (assuming there was room) new vm_page_t's could be added to the system to correspond to pages reclaimed from the preload area. This doesn't interfere with fictitious pages either (if anything, it'll simplify a fair amount of code that has to special case ficitious pages). Naturally, this is pipe dream stuff right now, but I'd like to take a shot at it in a month or two and see if I can sell DG on the idea. :-) Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812290642.OAA71584>