Date: 20 Mar 1997 11:22:45 +0000 From: Doug Rabson <dfr@render.com> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: terry@lambert.org (Terry Lambert), bde@zeta.org.au, dgy@rtd.com, hackers@freebsd.org, helbig@MX.BA-Stuttgart.De Subject: Kernel configuration futures (Was Re: wd driver questions) Message-ID: <sesp1qst8a.fsf@minnow.render.com> In-Reply-To: Michael Smith's message of Thu, 20 Mar 1997 13:28:20 %2B1030 (CST) References: <199703200258.NAA00691@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Michael Smith <msmith@atrad.adelaide.edu.au> writes: > > 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) One thing I will be doing with the NFS code is to separate the server and client code into two clean pieces. Instead of building a single module with both client and server, there will be two independant modules. I don't think they should have been together in the first place. > > > 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) Exactly. If kernel variables like #mbufs were controlled by a persistent sysctl database then performance tuning becomes trivial and certainly doesn't require re-linking the kernel with the 'server buffering module'. One could even write a flashy GUI thing for editing the variables. I don't think I have the strength for that though :-). > > > > 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. The kernel file ought to be a minimal system (no filesystems, no drivers) aggregated with some number of kernel modules. Filesystems and drivers and everything else would plug themselves into the kernel using sysinits. I think that the right way to do this is to have all drivers and filesystems which must be present at boot time (e.g. everything needed to find the root filesystem whether it is local or NFS mounted) statically aggregated with the kernel file (still modules, but essentially pre-loaded). Other modules which the administrator knows will be needed *could* also be pre-loaded but this is not necessary. After the root filesystem is present, the persistent configuration database is available. This will contain all that is needed to load modules for all pci, pnp, pccard devices that are detected. Legacy isa devices can be handled by having a list of drivers to load unconditionally and device parameters (irq, mem, etc) to use with those drivers. Once all the modules have been loaded from the root filesystem (and passed their probes), boot continues more or less as it does today. -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 734 3761 These are not the opinions of Microsoft. FAX: +44 171 734 6426
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?sesp1qst8a.fsf>