Date: Tue, 05 Jan 2010 07:49:35 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: Bcc-Receiver:; Subject: A blind carbon copy Message-ID: <20100105.074935.237540042763328076.imp@bsdimp.com>
next in thread | raw e-mail | index | archive | help
----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 <imp@bsdimp.com>
In-Reply-To: <alpine.BSF.2.00.1001050842340.75653@fledge.watson.org>
References: <alpine.BSF.2.00.0912122342110.61723@fledge.watson.org>
<20100104.150257.746477001028363176.imp@bsdimp.com>
<alpine.BSF.2.00.1001050842340.75653@fledge.watson.org>
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: <alpine.BSF.2.00.1001050842340.75653@fledge.watson.org>
Robert Watson <rwatson@FreeBSD.org> 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)----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100105.074935.237540042763328076.imp>