From owner-freebsd-stable@FreeBSD.ORG Fri Nov 4 14:39:47 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6ED3C16A41F for ; Fri, 4 Nov 2005 14:39:47 +0000 (GMT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1617943D46 for ; Fri, 4 Nov 2005 14:39:46 +0000 (GMT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id jA4EdkMG059241 for ; Fri, 4 Nov 2005 06:39:46 -0800 (PST) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.1/Submit) id jA4EdkAi059240 for stable@freebsd.org; Fri, 4 Nov 2005 06:39:46 -0800 (PST) (envelope-from david) Date: Fri, 4 Nov 2005 06:39:46 -0800 From: David Wolfskill To: stable@freebsd.org Message-ID: <20051104143946.GO69015@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , stable@freebsd.org References: <200511040039.RAA21926@lariat.net> <20051104023446.GA12859@xor.obsecurity.org> <6.2.5.6.2.20051103213504.09118d30@lariat.org> <20051104050118.GA46635@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051104050118.GA46635@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: Nogobble, nogobble X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2005 14:39:47 -0000 Hmm.... I confess I rather like the idea of being able to "include" chunks of kernel config to make my own, and well-understand the concerns that rwatson (for example) raised. I'm less familiar with the anti-foot-shooting concerns Kris raised. It seems to me that GENERIC is being used for a couple of rather distinct purposes: * As a kernel config that ought to work "out of the box" on most hardware (for the arch in question). * As a "base" config from which to begin customizations/mods. So I'm wondering if, perhaps, it might help to consider the following variant of the current theme: * Decompose GENERIC into a set if "functional blocks" of config info. * Then make GENERIC itself merely a set of "include" directives, perhaps with some commentary. Then when I want to create a kernel config for my laptop (which is unlikely, for example, to need very much RAID controller support), rather than including GENERIC and specifying a bunch of "nodevice" directives, I could copy GENERIC (as I've done before the "include" was available), see where the part is the includes the RAID controllers and either delete it or comment it out. Or, if I am of the mind to do so, I could *still* include GENERIC, then add "nodevice" directives. If this type of thing would help, I'd likely be willing to try my hand at the decomposition & PR submisison (with a patch or two). Peace, david -- David H. Wolfskill david@catwhisker.org Prediction is difficult, especially if it involves the future. -- Niels Bohr See http://www.catwhisker.org/~david/publickey.gpg for public key.