From owner-freebsd-hackers Fri Dec 12 15:45:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA06505 for hackers-outgoing; Fri, 12 Dec 1997 15:45:03 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA06480 for ; Fri, 12 Dec 1997 15:44:49 -0800 (PST) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id QAA22204; Fri, 12 Dec 1997 16:47:45 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp02.primenet.com, id smtpd021956; Fri Dec 12 16:47:01 1997 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id QAA16748; Fri, 12 Dec 1997 16:42:35 -0700 (MST) From: Terry Lambert Message-Id: <199712122342.QAA16748@usr04.primenet.com> Subject: Re: Why so many steps to build new kernel? To: AdamT@smginc.com (Adam Turoff) Date: Fri, 12 Dec 1997 23:42:35 +0000 (GMT) Cc: hackers@FreeBSD.ORG, daniel_sobral@voga.com.br In-Reply-To: <3491BC98@smginc.com> from "Adam Turoff" at Dec 12, 97 02:35:00 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >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.