Date: Thu, 20 Mar 1997 11:36:52 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dfr@render.com (Doug Rabson) 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: Kernel configuration futures (Was Re: wd driver questions) Message-ID: <199703201836.LAA14045@phaeton.artisoft.com> In-Reply-To: <sesp1qst8a.fsf@minnow.render.com> from "Doug Rabson" at Mar 20, 97 11:22:45 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > (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. Heh. We both pointed at the same fix. 8-). > > 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 :-). Personally, I don't like having tunables at all. I would prefer it attempt to allocate and fail on a resource shortage. It's very annoying to hit a hard limit with no good reason. There is only one reason for a hard limit: to prevent accidental "denial of service". The only reson for a soft limit is to prevent intentional "denial of service"... malicious attacks. If I need another mbuf (or other kernel resource), or I will error out some action, why, if I have the memory available, should I allow an error-out to ever occur? Why do I want what are (effectively) gratuitous errors? The whole concept of tunables needs to be revamped. > 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. YES, EXACTLY! There would be *no such thing* as a seperable module which did not self-register via sysinit(). The point of going to ELF, where you can have multiple segments in a given image is to remove the real need for linker sets altogether, and therefore the need for linking, rather than simple agregation of onjects with an object librarian that operates on an ELF "library". Give an loader that can load or force the unload of a self registering and unregistering ELF segment in an ELF image, loadable modules become ELF "libraries" on their own. This also lets me do things like "module TCP requires module IP" (for one example). It also lets me, after I get rid of the vfs_init code's dependence on the !@#%!@! FFS file system being statically linked for it to be able to get the struct vops size, replace the boot FS with any FS I want, including (for example) NTFS or VFAT32 or HPFS or EXT2FS, etc.. If the loader itself is similarly self-agregated (but statically), then I can use the same FS modules for the loader that I use for the kernel; in point of fact, if I leave the loaer code around, the kernel doesn't *need* an FS module other than that provided in the loader image. > 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. I still would prefer that everything "just work" without a registry. For PnP, EISA, MCA, or pure-PCI systems, this will work. For ISA systems, we've covered most of the danger cases (LANCE and NE200 probe, etc.) already. I still need a registry so that I can look up my component ID's for COM and/or CORBA and/or MS software installed on the system (in case we ever support WIN32), but little else. > Once all the modules have been loaded from the root filesystem (and > passed their probes), boot continues more or less as it does today. Yes, exactly. The boot critical devices go in, then the rest of the device go in once boot is done AND the device is present. The probe code is in ELF segments marked "discardable" and will load in the rest of the driver if the probe is true, but either way, the probe code itself is in pages which are reclaimed. The benefits are enormous... besides which, we fit in 4M again (who knows, maybe even 2M!). 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?199703201836.LAA14045>