Date: Wed, 17 Dec 1997 08:58:30 +1100 (EDT) From: Darren Reed <avalon@coombs.anu.edu.au> To: tlambert@primenet.com (Terry Lambert) Cc: daniel_sobral@voga.com.br, tlambert@primenet.com, hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? Message-ID: <199712162201.OAA03782@hub.freebsd.org> In-Reply-To: <199712161847.LAA18094@usr01.primenet.com> from "Terry Lambert" at Dec 16, 97 06:47:57 pm
next in thread | previous in thread | raw e-mail | index | archive | help
In some mail from Terry Lambert, sie said: > > > > The existance of mutually exclusive drivers is not friendly. > > > > Agreed. But do not forget that mutual exclusion is not the only thing being > > discussed here. You said prerequisites are not useful either. > > 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. > > > There are two types of exclusion: > > > > > 1) Screw up: the driver probes are antagonistic to other > > > hardware. This should be fixed by changing the probe > > > code. > > > > This may not always be fixed, as far as legacy hardware goes. > > 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. 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. > 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. btw, I can see FreeBSD taking a long time to bootup... > 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. > 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. > 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 ? Darren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712162201.OAA03782>