Date: Wed, 02 Dec 1998 18:13:16 -0800 From: Mike Smith <mike@smith.net.au> To: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> Cc: Mike Smith <mike@smith.net.au>, current@FreeBSD.ORG Subject: Re: KLD - what's the idea? Message-ID: <199812030213.SAA03115@dingo.cdrom.com> In-Reply-To: Your message of "Wed, 02 Dec 1998 18:53:46 MST." <199812030153.SAA57786@narnia.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> >> > Convert the entire kernel into an aggregation of KLD modules. Stick > >> > them together in interesting and versatile ways (eg. at build time to > >> > create a monolithic kernel, or at runtime to load/unload drivers, etc.). > >> > >> ... unload probe/init code when it is no longer needed. > > > > This is actually almost totally farcial; the only modules for which > > unloading probe/init code makes any sense are ISA drivers, and even > > then only ISA drivers that don't support PCCARDs. > > The probe and attach code for certain drivers is quite complex. The > Adaptec and NCR drivers do some amount of run-time firmware patching. > Several drivers carry along large firmware images that serve no purpose > once the image is loaded into the device. These situations would > certainly benefit from the ability to either selectively swap out > portions of a module (ala AIX) Hmm. It's been mentioned before that it would be relatively straightforward to put this sort of code into a separate section that could be marked pageable. I'd be concerned however that this would be incompatible with our current use of a 4M page for the kernel space - you'd have to somehow arrange to have these portions of the module located physically disjoint from the remainder of the module if I understand this correctly. > or to unload unused segments and > reload them on the fly during further probe/attach requests (ala Linux). It would certainly be feasible to arrange for the firmware images to be loaded from separate files, should that be an acceptable alternative. I'm open to suggestions on how to make this economical and robust... -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812030213.SAA03115>