From owner-freebsd-current@FreeBSD.ORG Tue Jan 5 14:51:40 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B0781065698; Tue, 5 Jan 2010 14:51:40 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 2DB168FC17; Tue, 5 Jan 2010 14:51:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o05EmqW1073989; Tue, 5 Jan 2010 07:48:53 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 05 Jan 2010 07:49:35 -0700 (MST) Message-Id: <20100105.074935.237540042763328076.imp@bsdimp.com> To: Bcc-Receiver:; From: "M. Warner Losh" X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Tue_Jan__5_07_49_35_2010_567)--" Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 05 Jan 2010 15:00:18 +0000 Subject: A blind carbon copy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 14:51:40 -0000 ----Next_Part(Tue_Jan__5_07_49_35_2010_567)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit This is a blind carbon copy. ----Next_Part(Tue_Jan__5_07_49_35_2010_567)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Date: Tue, 05 Jan 2010 07:49:35 -0700 (MST) Message-Id: <20100105.074935.914206331725098771.imp@bsdimp.com> To: rwatson@FreeBSD.org cc: arch@freebsd.org Subject: Re: May be include in GENERIC option INCLUDE_CONFIG_FILE? From: M. Warner Losh In-Reply-To: References: <20100104.150257.746477001028363176.imp@bsdimp.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit [[ moved to arch@, since the original discussion should have taken place there ]] In message: Robert Watson writes: : On Mon, 4 Jan 2010, M. Warner Losh wrote: : : > I'm planning on including standard files so that we can easily add : > things in one place instead of many that will be better than DEFAULTS : > in the next month or so. I've worked through several prototypes, none : > of which have been suitable to share with the wider world, but each : > one better than the one before... I'll post to arch@ when I have a : > proposal. : : Right, at this point what I'd really like to see is a : sys/conf/GENERIC, GENERIC.std or the like that we can add generic : things to in an MI fashion, which each architecture-specific GENERIC : can explicitly include. Yes. In general, I'm planning on having the following structure: std.board Most specific tweaking std.soc-family If appropriate std.core std.cpu std standard config for everybody Each layer would include the more generic thing and tweak it as necessary. Chances are there'd be multiple layers of "std"-ness, starting along a continum: "minimum" -> "everything-a-module defaults" -> "build-it-all-into-the-kernel defaults" -> "kitchen sink" -> "lint". However, having the ability to have that level of control gets a little trickier... One level of "bloat" is easy, but you start to run into problems if you want "bloat" to be tunable :) That's one axis of the problem. The other axis of the problem is including or excluding whole classes of devices. I don't want usb because my board has no USB at all. I want all of USB. I want all tty devices. I want all devices that are USB AND (wireless OR ethernet OR 3G). I want no SCSI controllers. I want all raid controllers. etc. One can try to attack this problem with include files, but it quickly falls down if you want to anything moderately complex (as in the last USB example above). This is where all my past overly-simplistic prototypes have faltered. It requires changes to config(8) that are fairly extensive because they affect config, as well as all the files* files in the tree, as well as needing some way to get the module dependencies that are enshrined in the .c files today... Warner ----Next_Part(Tue_Jan__5_07_49_35_2010_567)----