Date: Wed, 3 Jan 1996 13:07:37 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: koshy@india.hp.com (A JOSEPH KOSHY) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Demand loading (Re: FreeBSD, Zappa & PCI) Message-ID: <199601032007.NAA15377@phaeton.artisoft.com> In-Reply-To: <199601031031.AA299195067@fakir.india.hp.com> from "A JOSEPH KOSHY" at Jan 3, 96 04:01:06 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Well, it would be nice to be able to delay loading a driver till needed. > Even nicer would be the ability to unload and reload a driver on the fly. > > This would allow customers to update portions of the kernel without > having to bring the system down, (well, in theory, anyway :)). > > If I remember right Unixware had the ability to auto-unload an driver > which had been inactive for a while, freeing up memory and kernel > resources. Not so sure about SCO or Solaris ... UnixWare did unload delaying for in us modules, like file systems. This is not the same as "non-use timeout unloading", which is what you imply above. That implies a driver locality-of-reference model to determine an acceptable non-use period, and UnixWare does *not* have one of those. SunOS could unload modules, and the UnixWare code dervices from the Solaris code, so either way, I'd say Solaris has it. 8-). SCO may or may not have it. I implemented an LKM mechanism for my own use in adding system calls to SVR3 and SVR4.0.2 as a statically loaded device driver, very similar to the LKM mechanism in BSD, for support of SFD's in Dell UNIX, the original reference platform for the NetWare for UNIX (NWU) product. Dell had this annoying habit of identifying file systems by lexical order in the vfssw structure instead of by string (like System V), and they alphabetized the FS list as part of the kernel build. This was mostly to get around this one bogosity in a UNIX product that was otherwise superior to UnixWare in every point of system/user contact. So SCO *could* have it rather trivially if they wanted it, as long as they had a compiler that could generate PIC'ed .o files to get loaded and supported -r and -A, etc. > Can someone explain why we need ELF or its equivalent for this > to be feasible? It's not. ELF *is* desirable for having seperate segment ID's instead of seperate binaries for the transient probe/attach/detach code, which you would otherwise have to load into the kernel address space as a single lump, or as sperate object modules. Coff would also work for this, mostly. There are currently some issue in terms of object persistance, and these result in kernel memory space fragmentation being a definite problem in a fully dynamic load/probe/attach/detach/unload or load/probe/unload model (depending on if the device is there). Beyond that, the kernel interfaces exported by the kernel need to have their symbols available to the kernel space "linker" (really just a symbol relocator) and the export of symbols tagged by module ID and per module symbol resoloution usage counts would need to be maintained. Basically, the kernel symbols would have to live in the kernel data space, and the modules as they are loaded and unloaded would have to register/deregister addional exported symbols to allow them to be depended upon and unloadable. Finally system initialization critical drivers, like card specific syscons subdrivers, SCSI subdrivers, the SCSI driver itself, etc. all require a VM86() facility to truly allow you to have the minimal set of devices in the kernel at one time. Segment identification would allow such "fallback" drivers to be unloaded and discarded once the kernel had loaded the replacement drivers (and as such would have to preload as medium persistance objects, though the rest of the kernel was, by nature, high persistance). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601032007.NAA15377>