Date: Wed, 17 Dec 1997 06:09:10 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: avalon@coombs.anu.edu.au (Darren Reed) Cc: tlambert@primenet.com, daniel_sobral@voga.com.br, hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? Message-ID: <199712170609.XAA12007@usr09.primenet.com> In-Reply-To: <199712162159.OAA22556@smtp01.primenet.com> from "Darren Reed" at Dec 17, 97 08:58:30 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > No. I said prerequisites could be automatically handled by the KLD > > code, and so they are not necessary to specify in a kernel config. > > This is very different than say they are not useful (frankly, with > > the number of appeals I've made for graphical soloutions to problems, > > I'm surprised you could even think I meant that ;-)). > > Or you can try a kludge like solaris and have a symbol in a driver like > "_depends_on" specify any pre/co-requisites. Yes. I'd say that this was no more of a kludge than "ldconfig", since it's really nothing more than a cached value. You could get the same effect with ELF if you wanted by dynamically adding a new section of type symbol with one value in it for each module you depend upon once they've been identified. > > So far, it's always been fixable with probe order. Probe order can > > be specified using a priority field in the data in the driver image > > itself, and doesn't require a config file (or us one, in fact; the > > priority for the LANCE probe in the GENERIC image, for example). > > Bzzt. You have to load all the drivers then, to determine all the > priorities so you can probe them in the correct order. For small > memory machines, this might be somewhat of a problem when we get > to the stage of having megabytes of driver modules. Bzzt. You only need to be able to access the symbol tables of all the drivers (in pageable kernel memory) to be able to determine if a particular driver exports a symbol the driver you are loading cares about. In point of fact, there may be multiple drivers exporting a needed symbol, so you can't determine if the driver currently being checked needs to be loaded after one or the other. The correct way to deal with this is probably to delay the driver in question until you try one of the other driver(s) that export the needed symbol(s), and they load successfully. Then you can create an ELF section and cache the drivers the driver in question needs to load after -- a prerequisites, but one that is calculated dynamically without needing a human to intervene because the kernel is too stupid on its own. > My suggestion would be to have knowledge of *some* drivers builtin > to the kernel and then have init load the rest in an order specified > by some file. If the file is corrupt or shit happens, bailout and start > /sbin/sh. Sure. This is called "statically linking the drivers into the kernel such that they can be discarded and their space reclaimed if the driver is not used". Typically this will be unnecessary, since a driver will always have a lower priority than those drivers it depends on, unless the programmer screwed up. So if it gets to the point where the kernel will try to load it, then if the external references are not present, the load simply fails. This avoids the problem with your "prerequisites" scheme where you could potentially get into infinite loops because your dependency graph is not acyclic like it should be. > > The order of operation is dictated by the initialization order preference > > data. For your example of a third party driver to replace a FreeBSD > > driver, the obvious answer is to give the third party driver a higher > > priority. If present, it will get to the hardware first, and the > > FreeBSD driver's probe will fail, and it will be unloaded. > > How about just replacing the file (i.e. module) on the disk ? Renaming > it, if you like. That has worked for me in the past when dealing with > these sorts of problems. Or if you have a config file which mentions > drivers to use, etc, you remove the FreeBSD one and add the 3rd party > one instead. No. A config file implies a configurator. We don't want one of those. > btw, I can see FreeBSD taking a long time to bootup... I can't. We are presuming we can map the files for the drivers into the kernel address space. At the very least, this implies that we will only pull in the probe sections, if we don't go further and page driver code not in the paging path. We may want to mark the sections "preload" if the device is a swap critical or boot critical (before swap is going) device. > > If the driver is not boot critical, and you don't want it loaded > > (ie: an embedded system with a sound chip on the board but no > > speakers attached, etc.), then don't put the module binary into > > the directory where the kernel looks for module binaries. > > This solution also handles the multiple revisions of the same driver > problem. Yes. Not as neatly as giving the new version a higher priority. The problem here is that the old and new are likely to have the same name, and you would have a namespace collision on the file name in any case. This isn't as neat because you may need to down-rev a driver when the new one fails to run. > > This handles the "need/want to be loaded" cases. > > > > Your kernel configurator is /bin/ln, /bin/rm, and /bin/cp. > > How about /bin/mv ? It's a start, but a bit more would be nice. Well, I was thinking hard linking the module (or copying it, for those people who don't trust hard links -- the same people who type "ls' after deleting a file to make sure it's gone, from my experience ;-)) into the module directory from some common "possible modules" directory. I would prefer "cp" from the install media, but there's still the "downrev the driver" scenario. > > I haven't. I've only discussed how the problems you are attempting to > > solve via a kernel configurator should be solved instead, so that they > > require less user intervention, and do not violate the principle of > > least astonishment. > > How about the KISS approach ? Or has that fallen out of favour ? Well, it's much simpler to not have something a user has to run than to have something that the user has to run... that's KISS for user interface. If you mean KISS for implementation -- complexity for programmers is the natural result of implementing KISS for user interfaces, I'm afraid. An elephant wearing size 9 jeans is going to stick out somewhere... 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?199712170609.XAA12007>