From: Alessandro Rubini <rubini-list@gnudd.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [STATUS] Heads-up: Reorganize directory structure
Date: Fri, 16 Apr 2010 08:58:42 +0200 [thread overview]
Message-ID: <20100416065842.GA21982@morgana.gnudd.com> (raw)
In-Reply-To: <m2md66caabb1004151942s6ac4f444nac22bdccd128da6f@mail.gmail.com>
Graeme,
I reply to your messages since it gives somehow more information.
I'm now not really convinced that reorganizing board directories
would be a big step forward, although I still think it would be better.
Si, I'm not arguing strongly, just bringing a point of view.
Peter, Wolfgang, I'll try to do my homework and show how nhk8815/usb-s8815
would better share files when under cpu/, but I'm not sure to be able
to complete it before a week or so.
Graeme Russ:
> 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.
Yes, that would be good, if it was a common case. However,
arch-independent code is usually under drivers. See at91 and avr32 for
example: no common code under board/atmel/ . Even boards/freescale,
which has three architectures, has only MPC stuff in common/ (no arm
or coldfire files, checked by extracting the CONFIG_ symbols from
Makefile and grepping for them in include/configs)
> 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.
In theory you are correct. In practice, such platform independent
material is using drivers/ .
> And then there is also
>
> board/
> $BOARDC
> $BOARDD
>
> I've never liked code existing on multiple depths like this.
Agreed.
> Maybe we move towards:
>
> board/
> $VENDOR
> include/
> lib/
> $BOARDA/
> $BOARDB/
> $<cpu>_generic/
> $BOARDC/
> $BOARDD/
That's an option. But "$<cpu>_generic" is inferior to "cpu-$<cpu>". At
least listing will all "cpu-" directories nearby.
If there really was vendor-specific cross-platform code, I agree
something like you suggest is best.
/alessandro
next prev parent reply other threads:[~2010-04-16 6:58 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-13 9:23 [U-Boot] [STATUS] Heads-up: Reorganize directory structure Wolfgang Denk
2010-04-13 16:49 ` Ben Warren
2010-04-13 17:28 ` Stefano Babic
2010-04-13 17:29 ` Ben Warren
2010-04-13 19:24 ` Wolfgang Denk
2010-04-13 20:32 ` Remy Bohmer
2010-04-13 21:01 ` Wolfgang Denk
2010-04-13 19:22 ` Wolfgang Denk
2010-04-13 18:55 ` Remy Bohmer
2010-04-13 19:47 ` Jerry Van baren
2010-04-15 7:05 ` Michal Simek
2010-04-15 7:52 ` Wolfgang Denk
2010-04-15 15:04 ` Peter Tyser
2010-04-15 15:22 ` Wolfgang Denk
2010-04-15 15:31 ` Alessandro Rubini
2010-04-15 15:58 ` Peter Tyser
2010-04-15 17:58 ` Alessandro Rubini
2010-04-15 22:44 ` Peter Tyser
2010-04-16 2:42 ` Graeme Russ
2010-04-16 6:58 ` Alessandro Rubini [this message]
2010-04-16 7:50 ` Wolfgang Denk
2010-04-16 7:41 ` Wolfgang Denk
2010-04-16 11:45 ` Graeme Russ
2010-04-16 13:23 ` Wolfgang Denk
2010-04-15 23:14 ` Wolfgang Denk
2010-04-17 8:25 ` Graeme Russ
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100416065842.GA21982@morgana.gnudd.com \
--to=rubini-list@gnudd.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.