Date: Thu, 20 Mar 1997 13:28:20 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: terry@lambert.org (Terry Lambert) Cc: msmith@atrad.adelaide.edu.au, terry@lambert.org, bde@zeta.org.au, dgy@rtd.com, hackers@FreeBSD.ORG, helbig@MX.BA-Stuttgart.De Subject: Re: wd driver questions Message-ID: <199703200258.NAA00691@genesis.atrad.adelaide.edu.au> In-Reply-To: <199703200234.TAA12885@phaeton.artisoft.com> from Terry Lambert at "Mar 19, 97 07:34:02 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert stands accused of saying: > > > 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. That's the one. There's also quite a lot of code whose behaviour depends on various other options, but it would be practical in the short term to just compile several times with the sensible combinations of the various options and produce different modules. (I am thinking here fe. of NFS_NOSERVER) > 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. Debugging should always have been on a per-module basis; having a single kernelwide "DEBUG" define is clumsy. However 'debug subsystem' implies always-present debug hooks, which can be expensive. I don't like that much. > 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.. Most of that would be better handled (as implied by Doug R.) by a persistent attribute store (that R word) and dynamic allocation. I can't see myself loading a module with nothing but 1024 mbufs in its BSS 8) > > 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. You are still not listening 8); I have just said "when you discover you need the blocks, you can no longer read them because your load source has gone." This is an issue for the period from when control is transferred to the loaded kernel from the linker until a filesystem is mounted, and thus all the code that could possibly be required over that interval must be present. > Terry Lambert -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703200258.NAA00691>