[U-Boot] [STATUS] Heads-up: Reorganize directory structure
Graeme Russ
graeme.russ at gmail.com
Fri Apr 16 04:42:24 CEST 2010
On Fri, Apr 16, 2010 at 1:58 AM, Peter Tyser <ptyser at xes-inc.com> wrote:
> Hi Alessandro,
>
> On Thu, 2010-04-15 at 17:31 +0200, Alessandro Rubini wrote:
>> I can see how it'd be
>> >> nice to split up boards into CPU directories, but we'd have to discuss
>> >> some of the warts, like where vendor-specific code would be located if
>> >> we went down that path.
>> >
>> > Right. I can see arguments pro and con each of the approaches, and I
>> > must admit that I have no telling argument for either.
>> >
>> > My gut feeling is that I like the existing board/ approach better, but
>> > I'm open to arguments.
>>
>
> My understanding is that currently we have:
> board/
> $VENDOR/
> $BOARDA
> $BOARDB
>
Almost - it is more like
board/
$VENDOR/
include/
common/
lib(?)/
<etc..>/
$BOARDA/
$BOARDB/
I really like this structure, particularly if the code under
$VENDOR/[common, include, lib] is arch independent. If a vendor
develops a new board using a different CPU or SOC they can easily re-use
all their pre-existing platform independent code for the new board.
Maybe we should look at moving CPU & SOC specific code from board/$VENDOR
into arch/ which will probably consolidate a lot of common code loitering
around in the various board directories.
And then there is also
board/
$BOARDC
$BOARDD
I've never liked code existing on multiple depths like this. Maybe we move
towards:
board/
$VENDOR
include/
lib/
$BOARDA/
$BOARDB/
$<cpu>_generic/
$BOARDC/
$BOARDD/
Any code that would otherwise live under $<cpu>_generic/[include, lib]
should (by definition) be moved to arch/$<cpu>/[include, lib]
Regards,
Graeme
More information about the U-Boot
mailing list