On Fri, Apr 16, 2010 at 5:41 PM, Wolfgang Denk <w...@denx.de> wrote: > Dear Graeme Russ, > > In message <m2md66caabb1004151942s6ac4f444nac22bdccd128d...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
