A blind carbon copy

This is a blind carbon copy.

attached mail follows:

[[ moved to arch_at_, since the original discussion should have taken
   place there ]]

In message: <alpine.BSF.2.00.1001050842340.75653_at_fledge.watson.org>
            Robert Watson <rwatson_at_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_at_ 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