Skip site navigation (1)Skip section navigation (2)
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>