From owner-freebsd-hackers Wed Jan 22 00:58:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA23701 for hackers-outgoing; Wed, 22 Jan 1997 00:58:57 -0800 (PST) Received: from profane.iq.org (profane.iq.org [203.4.184.217]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA23686 for ; Wed, 22 Jan 1997 00:58:36 -0800 (PST) Received: (from proff@localhost) by profane.iq.org (8.8.4/8.8.2) id TAA08248; Wed, 22 Jan 1997 19:57:22 +1100 (EST) From: Julian Assange Message-Id: <199701220857.TAA08248@profane.iq.org> Subject: kernel configuration In-Reply-To: <28199.853858730@time.cdrom.com> from "Jordan K. Hubbard" at "Jan 21, 97 06:58:50 am" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 22 Jan 1997 19:57:21 +1100 (EST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Have you considered adapting the current visual kernel > > options code to manage compile time options as well? > > It seems to me that this would provide a very nice > > unified interface. Brief descriptions of the device > > could be displayed in an additional horizontal region, > > perhaps augmented with a computer readable flag mask > > description language. > > Yes, we've definitely considered it. Unfortunately, there's > no framework for it and the compile-time options also do more > than just set variables which sysinstall might be able to tweak > afterwards, they selectively compile sections of code and how do > you conditionalize THAT after the fact? :-) Well, you don't need to, after the fact, because if the code ain't there - it ain't there ;) > Maybe someday, but it's going to take some major work > on the whole configuration paradigm. Speaking of which, I wonder if it is time the kernel dependency system was rationalised. I rationalised the linux equivalent (which was (is?) a real shocker) by writing code to find every configuration macro, and separate them out into individual .h files included by the code that referred to it. This is similar to the current opt_foo.h scheme FreeBSD has now. I feel a little woosey looking at -DFFS -DIPDIVERT -DINSERTYOURUNDEPENDABLECPPDEFILEHERE's marching up my screen during a kernel compile. A define which does nothing is pointless and a define which does something potentially changes code and so must be referred to as dependency by the code it effects. The only command line define that is acceptable is -DKERNEL. On a slight tangential, has thought been given to clustering kernel text/bss initialisation code at the start or end of the image and lopping it all off once the last piece of init code is called? Cheers, Julian.