From mboxrd@z Thu Jan  1 00:00:00 1970
From: <bogus@does.not.exist.com>
Date: Tue, 19 Aug 2008 20:18:26 -0000
Subject: No subject
Message-ID: <mailman.32.1219177159.21156.u-boot@lists.denx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

    - What CPU Architecture is being targeted?
      (ARM, MIPS, PPC, Xscale, etc)

    - Given the CPU Architecture is now known, which processor
      is being selected?  This might involve an intermediate step
      in which a "family" of processors might be selected to help
      narrow the selection.  For example, maybe it is OK to just
      offer the 7 XSCALE processors directly (ixdp425, xm250, etc),
      while the prolific PPC might do a PPC4xx, 82xx, 85xx, etc
      selection for family in order to get to a specific cpu
      such as the mpc8540.

    - What board is being targeted?
      (ADS, CDS, IceCube, etc)
      Basically anything in u-boot/boards that is appropriate
      for the given target CPU Arch or specific CPU.

I think that one of the key factors where a new configuration
system could win, in general, is in "enforcing bad combinations".
One component that would get encoded into the config files would
be, for example, the knowledge of what CPUs are supported on
which boards.

> For me, the following topics are important:
> 
> * clearness and readability of the resulting  code  /  config  files;
>   this  includes  having  all  relevant  information  for  one  board
>   concentrated in very few well known files.

Could I ask you to clarify this point a bit, please?  I'd like to
understand what your concern here is.  In particular, I think that
there is a bit more of a "cross product of features" available and
that some degree of horizontal slicing rather than vertical slicing
of the options might be needed.  In that way, it is not so much tied
to a particular board.

Thinking out loud still.

Thanks,
jdl