Date: 21 Mar 1997 11:51:44 +0000 From: Doug Rabson <dfr@render.com> To: Terry Lambert <terry@lambert.org> Cc: msmith@atrad.adelaide.edu.au, 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: <selo7hsbsf.fsf@minnow.render.com> In-Reply-To: Terry Lambert's message of Thu, 20 Mar 1997 11:36:52 -0700 (MST) References: <199703201836.LAA14045@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert <terry@lambert.org> writes: > ... > > The whole concept of tunables needs to be revamped. Some tunables are necessary. It should, however, be possible to tune things by say: # sysctl -w kern.i386.physmem=128M # or something # sync # reboot This seems a damn sight easier than editing a config file, rebuilding the kernel, installing it and then rebooting. > > > > 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". You don't really need ELF for this, actually. If a driver module registers itself with sysinit, then it can be just added to the kernel link if you want it statically loaded. When loading the module dynamically, the kernel should run any sysinits contained in the module at load time. The module doesn't need to act differently in the two cases. > > 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). Hmm. Somehow I doubt that many people would load IP without TCP :-). Dependancies in general would be useful for modules. That is probably where ELF has the edge. For instance, to get back the NFS example, both the client and the server share some utility code for doing RPC. If there were three modules, this works nicely: nfs_rpc_mod.o # RPC support code for client and server nfs_mod.o # NFS client, depends on nfs_rpc_mod.o nfs_serv_mod.o # NFS server, depends on nfs_rpc_mod.o When loading nfs_mod.o or nfs_serv_mod.o, nfs_rpc_mod.o would load automatically if not already present. > > 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. See my other reply. I think the restrictions of running in the loader (size and non-interrupt-driven i/o) make the use of a full-blown filesystem impractical. > > > > 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. For PCI, PnP etc, I still think there needs to be a registry. The registry would have a mapping from pci device id to driver module name. The alternatives are to embed the device id in the module name, giving something like dev_8086_1229_mod.o for the fxp driver or to load all known drivers and let the probes sort out which ids they match. Neither approach works very well. Some drivers support many device ids and the idea of loading all drivers and only keeping the ones which probe just doesn't scale very well. > > > > 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. Not convinced. I don't want to have to probe possibly hundreds of drivers when there are only a couple of devices in the system. It should work in the other direction. The PCI device scan gives a list of ids. These ids are looked up in the registry to find possible drivers and those drivers are loaded. The only code which is loaded is code which is likely to be needed. When a new driver is installed (possibly in binary form from a vendor) it would hook itself into the registry for all the pci ids which it can support. > > The benefits are enormous... besides which, we fit in 4M again (who knows, > maybe even 2M!). Lets not get too optimistic. For the install disk, a lot of drivers still need to be present, either statically in the kernel or on the compiled-in MFS and that still takes up space. -- 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?selo7hsbsf.fsf>