From owner-freebsd-current Sun Sep 24 16:39:02 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA21785 for current-outgoing; Sun, 24 Sep 1995 16:39:02 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA21770 for ; Sun, 24 Sep 1995 16:38:58 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA04174; Sun, 24 Sep 1995 16:36:16 -0700 From: Terry Lambert Message-Id: <199509242336.QAA04174@phaeton.artisoft.com> Subject: Re: kernel versions and config's rm -rf To: fenner@parc.xerox.com (Bill Fenner) Date: Sun, 24 Sep 1995 16:36:16 -0700 (MST) Cc: terry@lambert.org, current@freebsd.org In-Reply-To: <95Sep24.150638pdt.177475@crevenia.parc.xerox.com> from "Bill Fenner" at Sep 24, 95 03:06:35 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1567 Sender: owner-current@freebsd.org Precedence: bulk > The other solution that I was considering was reading the number out of > the "version" file before the "rm -rf" and then writing it out again > afterwards. I'll write that instead, if it would make you more comfortable. Yes, please. This keeps the breakage in the dependency graph (which will hopefully some day be fixed) sperate from the config, which removes far more than it really has too, but does so because the dependecy graph breakage is hidden from it. I'm wondering at the existance of compile time optioning in the first place. Really, it exists because the device driver and other subsystems don't have explicit registration mechanisms that don't depend on static data. Proper use of the SYSINIT() mechanism is 50% of the answer, and the devfs work Julian is currently doing is another 20%. Probably 30% still remains as architecture problems in the device probe, PCI bridging, Interrupt attach, Interrupt sharing, and manifest constant controlled code variations, which should be sysconfig items. Still a lot of work. Config at that point will need to put together a Makefile, and potentially reference existing third parth object modules for optioned devices (like smart serial port drivers for which source is not available, etc.). So evenetually, the config we know should go away; at the very least, the generated header files with device and pseudo-device count definitions should die, die, die. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.