Date: Sat, 22 Mar 1997 17:56:49 +0000 (GMT) From: Doug Rabson <dfr@nlsys.demon.co.uk> To: Terry Lambert <terry@lambert.org> Cc: Doug Rabson <dfr@render.com>, 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: <Pine.BSF.3.95.970322173301.333B-100000@kipper.nlsystems.com> In-Reply-To: <199703211759.KAA15960@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 21 Mar 1997, Terry Lambert wrote: > > > > 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-(. I think that in the long run, this might be useful but only marginally. The only modules which should be included in the static kernel are ones which will be used. Including dozens of drivers in the kernel only to ditch them later is just wasteful. It also seems to me that to be able to discard a module from the static kernel, you would need to pad all its sections to VM pages so that you can re-use the pages. This also sounds wasteful. > > > > > 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-). That is the other way around, TCP without IP. Is that possible? I thought the normal streaming protocol for IPX was SPX or something. I know very little about Novell.. > > > > 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). The link/load should definately be in the kernel. I firmly believe that the cost of the runtime symbol tables is well worth the gain of allowing inter-module dependancies, and kernel-initiated module loads. > > > > 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. Any changes to this area are going to take far too long. I want to get something practical and small working fairly quickly. Bells and whistles can come later. > > > > 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. The reason I want the probe to be data-driven rather than code-driven (the way it is today) is to make installing a new driver trivial. > > 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. This would work I guess. It still means scanning all the drivers, opening the files etc. How does it get a complete list of drivers? One way might be to force all pci driver modules to be installed in a single directory (e.g. /lkm/pci/*.o or whatever). Even if the device id information is embedded in a section of the ELF file, I still think it is better to compile a single index file by scanning the drivers at install time. > > 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. Again, this is way in the future. Lets try and do something that is possible today, otherwise it will never get done. > > > 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). The install floppy's MFS does take up space in RAM. For the install disk, it still makes sense to statically include as many drivers as possible. The GENERIC kernel that gets installed can be *much* simpler. -- Doug Rabson Mail: dfr@nlsys.demon.co.uk Phone: +44 181 951 1891
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.970322173301.333B-100000>