Date: Fri, 21 Mar 1997 10:59:12 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dfr@render.com (Doug Rabson) 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: Kernel configuration futures (Was Re: wd driver questions) Message-ID: <199703211759.KAA15960@phaeton.artisoft.com> In-Reply-To: <selo7hsbsf.fsf@minnow.render.com> from "Doug Rabson" at Mar 21, 97 11:51:44 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. Why reboot at all? 8-) 8-). Oh, god, now we need a "safe mode" for recovery from someone saying they have 256M of memory when they only have 16M (maybe they saw an "add more memory" error message? 8-)). > > 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. Yes... the difference is, I want to be able to pull a module from an already linked kernel, and to do that, I have to deagregate the linker set data agregated from that module. 8-(. > > 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 :-). Novell? TCP/IPX... 8-) 8-). > 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. This could be done by moving the link/load phase into the kernel, actually, without needing ELF. The ELF issues come into play when you want to reclaim space after an unload, or otherwise defrag your VM. I'm loathe to put each driver in its own unique VM for obvious overhead reasons (cv: "MACH vs. CHORUS" ad infinitum). > 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. Depends on how well defined the VFS bottom end becomes. I think the current state of affairs in this regard is abysmal... there are some 120 or so kernel interfaces required to support the full Heidemann framework. This is an unacceptable bottom end. > 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. Or to load a "metaprobe" module that knows which modules to load based on ID. 8-). That's how PnP services in Win95 operate, to some extent; it's just that the module references a registry. But there's no reason the module has to be implemented taht way. If you abstract at that level, the implementation can be opaque. It *should* be opaque so you don't have to have all your code working at once time to test part of it. > > 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. You don't need a registry for this (as above). If you don't like the "metaprobe" idea, rather than scanning the registry, it could look for an ELF segment "device data" in the files before it loaded them; either way, a real registry is not really necessary. I like the idea of the registr not being boot critical because I like the idea of putting the registry data into an LDAP server and doing central administration on all my machines by operating against the directory. If you require the registry, then you have to go full branching (that's not an LDAP capability, you'd need the whole X.500, which is a bear). It's the chicken-and-egg problem for network authentication instances for UNIX systems. How do I authenticate a kerberos ticket before I'm running processes which have credentials without the ticket associated with them? This is the same problem that UnixWare and NDS integration faced. > 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. Or just have a segment with those ID's in it, or have a discradable code segment that a metaprobe knows how to load... > > 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. But they do not take up space in RAM, unless they are used (assuming you have kernel paging support on at least a segment color boundry). 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?199703211759.KAA15960>