Date: Wed, 19 Mar 1997 19:34:02 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, bde@zeta.org.au, dgy@rtd.com, hackers@FreeBSD.ORG, helbig@MX.BA-Stuttgart.De Subject: Re: wd driver questions Message-ID: <199703200234.TAA12885@phaeton.artisoft.com> In-Reply-To: <199703200006.KAA29110@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Mar 20, 97 10:36:43 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Yes. This should go. So should all configuration options that > > cause conditional compilation of code rather than conditional > > inclusion of objects in the link which extend a global linker set. > > That's a lot harder. I would say "some" rather than "all". Can you, off the top of your head, think of any code that can be conditionally compiled, but should not be made modular? About the only code I can think of is the "#if DEBUG" type code. If you localize the "#if DEBUG" as "#if DEBUG_SUBSYSTEM", and create a depedency for the subsystem (by linking it to a single object before linking it to the kernel) than that should go away as well, or at least become sufficiently comparmentalized that you don't have the structures changing out from under you when some modules are compiled with the conditional and some are compiled without. > > If you get rid of conditional compilation, and leave only conditional > > inclusion, then you remove the need for recompile on conditional > > changes, and it becomes a binary/linker issue *only*. This is a *good* > > thing. > > Be wary of increasing the linkage overhead too much 8) I think linkage overhead is where module boundries belong. This lets me have commercial or quasi-commercial (like an Adaptec driver using HIM under non-disclosure by *only* the driver author) module that I don't have to worry about compilation dependencies when I set my comparmentailized flags. Specifically, I'd like to see options for kernel resource management handled via linker-set agregated data structures, highed bidder in the set wins (or better, agregate wins). This would let me provide minimal per-module resource requirements on a per-module basis, and still let me override by commiting an addition 'n' resources. Big win; for instance mbuf counts for big server sites, max subprocess counts for big user sites, etc.. > > They *could* be sparsely loaded. You do not need paged memory > > management to support partial loading (look at Win3.1 DLL's). > > Understood; the point merely being that much of the kernel may be > required _before_ there is any method available again to load the bits > that were left out. A standalone boot-time linker and associated > media drivers are going to be long gone before the kernel is in a > position to talk to the media again. If you can read the blocks, and the load was sparse, you can fill in the sparse pieces. The trick would be knowing that you need to do it; you could handle that by unmapping the allocated-but-unpopulated regions. Not much sense in doing this; all it saves is load time if most of your code in the load path is not in the run path... this is only useful if your modules do not each end up in their own virtual address space like they should, since you wouldn't have to reclaim areas where you loaded (for instance) device code for a device that didn't probe true. Marking the probe code discardable means you can recover the whole area, sperate KVA or not, for things that didn't probe as present. For a PnP OS, the BIOS has the option of not PnP enabling non-boot-ctritical devices (many people believe this is an error in the PnP specification). Regards, 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?199703200234.TAA12885>