Hi Dirk,
>> Well actually (I think) we agreed on doing the board/vendor scheme. For
>> example look at board/amcc - there are all the AMCC evalboards basically
>> each one with a different SoC. Turning this around into board/<soc>
>> would throw pieces all over the places, which is definitely not what we
>> want.
>
> Yes, I agree that it makes no sense to *completely* change the rule.
>
> Maybe we should just be a little bit more flexible about this rule and
> have look, where something else makes more sense.
I doubt that we can be more flexible with this rule without effectively
introducing another rule. After all, that's what you say: "generally we
follow rule a, only if it doesn't make sense (which one cannot tell
beforehand) and then we follow rule b".
Such a "metarule" is not a big help - precisely because one cannot tell
beforehand which "sub-rule" is applicable.
>> Let's look at it from this perspective - on a board level there is
>> really more adhesion between two different cpu boards from one vendor
>> than between two same cpu boards from different vendors. Just take the
>> AMCC boards - they all have the same feel to them, so this is the
>> natural way to group the boards.
>
> I could add the opposite example:
>
> A <vendor == TI> OMAP3 based board (e.g. Beagle) has no adhesion with
> a <vendor == TI> DaVinci board.
To which I reply - then TI should better shape up their U-Boot support
and get the boards in line ;)
>> Even more, sharing of stuff should be done outside of board/ - if it
>> applies to all omap3, common stuff should be in cpu/arm_cortexa8/omap3
>> and *not at all* below board/.
>
> Sounds like you propose to put omap3 *board* common stuff into *cpu*
> directory?
No way. I only say that stuff which boards have in common *additional*
to what they share from their architecture *should* be very little.
Ideally a board/ directory is *very* light. The heavyweight stuff
should be below cpu, drivers, etc.
>> Finding boards with the same architecture was always very easy by
>> grepping the include/config/* files. We do not need a representation of
>> this fact below board/.
>
> But it wouldn't hurt?
It hurts if it stops us from having a single rule.
>> But still, we had this discussion already and I do not see that
>> anything fundamental has changed since the last time around, so
>> please let's not got into bike-shed painting right now ;)
>
> Could we agree to be more flexible with this rule?
>
> Or, the other way around:
>
> Independent of the rule, do you see any advantage of switching existing
>
> board/omap3/
> board/davinci/
>
> into something like
>
> board/DigiKey/beagle (or board/TI/beagle?)
> board/gumstix/overo
> board/mistral/evm (or board/TI/evm? )
> board/xx/pandora
> board/zz/zoom1
> board/yy/zoom2
>
> etc.?
>
> Except to follow the rule?
A rule is only good if it really helps to organize stuff. So yes, I see
an advantage of the latter examples, namely that someone looking into
board/ has a single rule which will allow him to find what he is looking
for.
Cheers
Detlev
--
I talk to planets baby
-- Dave Wyndorf (Monstermagnet)
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
