From owner-freebsd-hackers Mon Dec 15 10:20:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA21404 for hackers-outgoing; Mon, 15 Dec 1997 10:20:30 -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 KAA20761 for ; Mon, 15 Dec 1997 10:15:21 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id LAA27631; Mon, 15 Dec 1997 11:14:53 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpd027555; Mon Dec 15 11:14:28 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id LAA18539; Mon, 15 Dec 1997 11:14:23 -0700 (MST) From: Terry Lambert Message-Id: <199712151814.LAA18539@usr05.primenet.com> Subject: Re: Why so many steps to build new kernel? To: daniel_sobral@voga.com.br Date: Mon, 15 Dec 1997 18:14:23 +0000 (GMT) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: <8325656E.003FF988.00@papagaio.voga.com.br> from "daniel_sobral@voga.com.br" at Dec 15, 97 08:45:43 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The idea that there needs to be a mechanism for handling mutual > > exclusions presupposes (incorrectly, IMO), that some drivers are > > mutually exclusive. > > Well, as far as I know, syscon and the vt stuff are mutually exclusive. > And, generally, speaking, two drivers to the same piece of hardware will be > mutually exclusive. That's not that unlikely to ignore the possibility. The first one to grab the hardware gets it. If you want to prefer one driver over the other, you link it first so it gets first shot at the SYSINIT. If you want to configure one to be first at run time instead of at link time: use an ELF archiver. > > Similarly, prerequisite identification is well and good, but can be > > done symbolically, without reference to a kernel configurator. > > Similarly, the kernel configurator should not display syscon's history > buffer size option if you did not select syscon. A data section groveller would allow you to set this type of thing; we currently have three of them, counting sysinit/rc.conf. > > So what's left for a kernel configurator to do? > > > ...Nothing. > > In a perfect world, with elf kernel, PnP PCI devices, devfs, and well > behaviored hardware, sure, nothing's left to do. > > (except that, there probably would be even then) So why work on (or argue heatedly about) code that's going to go away? There's no need for a build-time configurator, in any case. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.