Hi Albert,
On 1 February 2015 at 03:11, Albert ARIBAUD albert.u.boot@aribaud.net wrote:
Hello Simon,
On Sat, 31 Jan 2015 20:20:06 -0700, Simon Glass sjg@chromium.org wrote:
Hi Albert,
On 31 January 2015 at 20:02, Albert ARIBAUD albert.u.boot@aribaud.net wrote:
Hello Masahiro,
On Sun, 25 Jan 2015 15:11:02 +0900, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
This series can be applied on the current u-boot/master (commit 37b608a52dcb133)
I'd rather not have all mach-* directories just below arch/arm/. Can't they be created under arch/arm/soc/ instead? That would give a cleaner structure IMO.
It does save a level and I am forever typing cpu/armv7 to get what feels like nowhere...
That can easily be solved (and tuned to personal taste) with CDPATH, eg.
uboot@lilith:~/src/u-boot-arm (master)$ export CDPATH=arch/arm/cpu:arch/arm uboot@lilith:~/src/u-boot-arm (master)$ cd armv armv7/ armv8/ uboot@lilith:~/src/u-boot-arm (master)$ cd armv7 /home/uboot/src/u-boot-arm/arch/arm/cpu/armv7 uboot@lilith:~/src/u-boot-arm/arch/arm/cpu/armv7 (master)$
(the u-boot-friendly value of CDPATH can put in a u-boot_env.sh file to be sourced along with other u-boot related settings)
I almost never cd into these directories. Mostly I have an editor/IDE open and I use File->Open to find the files. So this does not help me. But also I'd say that if the extra levels have no value then why do we have them at all?
this is what the kernel does and it does seem convenient.
Well, to me it does not really -- I'm ok with loads of mach-* subdirs under a commin parent dir, but what's the benefit of mixing mach-* dirs with non-mach-* ones?
If you look at tegra it has its code split between armv7 and arm720t. This makes it harder to understand what is going on if you are trying to follow the SPL/U-Boot early boot sequence on tegra. It is nicer to have all the tegra code under a tegra/ directory regardless of the particular ARM core.
I think the ARM core name is a convenient way of splitting things up and has served us well. But now the common elements are more at the SOC level. Yes the idea of arch/arm/soc/mach-... is more pure from a hierarchical point of view, but arch/arm/mach-... would be my preference. I feel that arch/arm is underused now, and U-Boot is growing so we should try to 'balance' the source tree, making sure each level of the hierarchy justifies itself with enough files/subdirs, etc.
$ ls arch/arm config.mk cpu dts imx-common include Kconfig Kconfig.debug lib Makefile mvebu-common
Note that there are two 'common' directories in there already - see for example this commit:
commit ea00e59be08989dae905076f4acf3eb297fce552 Author: Stefano Babic sbabic@denx.de Date: Wed Sep 5 20:16:36 2012 +0000
MX: set a common place to share code for Freescale i.MX
Up now only MX5 and MX6 can share code, because they have a common source directory in cpu/armv7. Other not armv7 i.MX can profit of the same shared code. Move these files into a directory accessible for all, similar to plat-mxc in linux.
One more point is that there is some benefit to using a similar approach to Linux so long as it is reasonably sensible - familiarity, less confusing when switching projects.
If we follow this approach then I suspect that arch/arm/cpu will be only for the 'ARM core' code, not the vendor-specific SOC code built up around it.
Regards, Simon