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