[U-Boot] [STATUS] Heads-up: Reorganize directory structure

[Graeme Russ]

On Fri, Apr 16, 2010 at 5:41 PM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Graeme Russ,
>
> In message <m2md66caabb1004151942s6ac4f444nac22bdccd128da6f at mail.gmail.com> you wrote:
>>
>> And then there is also
>>
>> board/
>>   $BOARDC
>>   $BOARDD
>>
>> I've never liked code existing on multiple depths like this. Maybe we move
>> towards:
>
> But we're just about adding exactly such multi-depth structures to
> the CPU directory (see recent discussion about "ARM: reorganize
> Cortex directory").

Hmmm, but this move makes sense unlike the current board/ structure
(or lack thereof). In the ARM Cortex case, only cortex 8 code will
exist under arch/arm/cpu/cortex/a8. At the moment, nearly every
arch has a representative one level below board/

One could go as far as board/$ARCH/$VENDER with a board/$ARCH/generic
failover, but that means if a vendor wants to share code between
different arch's they are a little hamstrung. Going down this path
might lead one to think $ARCH/$BOARD/$VENDOR/ with $ARCH/$BOARD/generic
but this is a completely illogical place to look for a vendors board
because you should not need to know what CPU/SOC a vendor is using
for their board, just the vendor and board ID should be enough.

>
> If you don't like this you should raise your voice in that thread.
>
>> board/
>>   $VENDOR
>>     include/
>>     lib/
>>     $BOARDA/
>>     $BOARDB/
>>   $<cpu>_generic/
>>     $BOARDC/
>>     $BOARDD/
>
> I see not much benefit in artificially distributing the misc boards
> into several directories.

The problem with the current structure is that there is no way of
knowing which $BOARD in board/ uses a particular CPU or SOC. Therefore
when one goes looking for examples of how to implement their brand
spanking new super-duper board using SOC 'x' which does not exist under
a $VENDOR/ dir they have to 'go fish'. By moving all boards which use
the same CPU or SOC under a common folder, looking for an example board
is much easier. Maybe $[cpu, soc]-generic/ might be better

>
>> Any code that would otherwise live under $<cpu>_generic/[include, lib]
>> should (by definition) be moved to arch/$<cpu>/[include, lib]
>
> That makes even less sense to me. Such could would usually be highly
> board specific. [There are of course lots of bad examples, where

Board specific code would always live under $[cpu, soc]-generic/$BOARD

> generic code gets copied & pasted from one board directory to the next
> one and so on, but factoring out such common code is a task that is
> orthogonal to this discussion, i. e. it could be done in the existing
> directory structure (or any other) as well.

Exactly - Any code that exists under multiple existing $BOARDx dirs
which is only duplicated 'by bad example' and is, in reality, CPU or SOC
specific should be moved into the appropriate arch/ dir. Once the
/board/$[cpu, soc]-generic/$BOARD move has been been done, identifying
the duplicate code will be that much easier


Regards,

Graeme