Date: Fri, 12 Dec 1997 23:42:35 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: AdamT@smginc.com (Adam Turoff) Cc: hackers@FreeBSD.ORG, daniel_sobral@voga.com.br Subject: Re: Why so many steps to build new kernel? Message-ID: <199712122342.QAA16748@usr04.primenet.com> In-Reply-To: <3491BC98@smginc.com> from "Adam Turoff" at Dec 12, 97 02:35:00 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >I don't think name/class/description is enough. We ought to identify > > prerequisites and mutual exclusions (see syscon and vt drivers for an > > example of both situations). > > Sure, but (no offense) the prerequisites and mutual exclusions should > be handled better than the ports collection is (for example). > > I seem to remember that RPM had a good idea of what a > 'core' product is and what an 'upgrade' is so that when > you upgrade, your dependencies are migrated to the > new version of the product. > > Or am I getting ahead of myself WRT kernel configs? I think everyone is getting ahead of themselves. The idea that there needs to be a mechanism for handling mutual exclusions presupposes (incorrectly, IMO), that some drivers are mutually exclusive. If this is the case, the thing to fix is the drivers, not to add the ability to do mutual exclusion into a kernel configurator. Similarly, prerequisite identification is well and good, but can be done symbolically, without reference to a kernel configurator. So what's left for a kernel configurator to do? Basically, it's to let a human do device probes on its behalf. This seems buggered to me. It seems to me that the driver should be able to do its own probes without "calling a procedure embedded in a human" to do the job. In other words, it's an issue of writing the appropriate driver probe code. So what's left for a kernel configurator to do? The only thing I can think of is to draw a distinction between "boot critical" and "non-boot critical" devices. But you can know that already, if you know the kernel design well enough. Certainly, the Makefile's whould know the kernel design well enough. That's what they are there for. So the distinction between "boot critical" and "non-boot critical" can be made at the "is linked into the kernel" and "is dynamically loaded into the kernel after boot is complete". In other words, the liker targets in the default Makefile. So what's left for a kernel configurator to do? ...Nothing. 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?199712122342.QAA16748>