In message 1083341111.5420.15.camel@gleep.sps.mot.com you wrote:
I confess, I am not sure what constitutes "genial" here. From the high-level perspective, my current notion is to roughly ask three basic questions at the onset:
- 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.
Isn't that 300% redundand already?
Why do I need to select an architecture and a processor when I know I have an IceCube board which will never be ARM and never be fit with a MPC860 processor?
At this stage, all you need to select is the board type.
I think that one of the key factors where a new configuration system could win, in general, is in "enforcing bad combinations".
"enforcing bad combinations"??? You must be joking.
One component that would get encoded into the config files would be, for example, the knowledge of what CPUs are supported on which boards.
Which improvement would that give? Right now you select a target config name, like "TQM860L". Nobody needs to know more.
- 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.
I'm thinking about how I spend my time. For me, working with U-Boot involves several tasks:
(1) porting new architectures/processors/boards; we do this for a living so it must be possible to do this in a very efficient way - at least not more complicated or with more overhead than we have now.
(2) adding customizations, add-on's, new features; again, this must be easily possible with minimal overhead.
(3) adding contributed code for other developers; I do this in my free time, so it must be especially easy do to.
(4) making sure the whole system is as clean and stable as possible; again I do this in my free time, and this is a very limited and precious resource
At the moment, you can add basic support for a new board within half an hour if you know the code as we do and if you manage to find a reasonable similar board as model. OK, to get it ready for release will usually take a few more days, but that's it.
I definitely don't want to have to add 25 new files with meta- or config data just to get my job done.
From your 3-questions approach to system configuration above I got
goose bumps all over my neck - this is something I will not accept.
Best regards,
Wolfgang Denk