On 11/15/2015 09:32 PM, Masahiro Yamada wrote: > 2015-11-15 14:38 GMT+09:00 Nishanth Menon <n...@ti.com>: >> On 11/14/2015 05:56 PM, Masahiro Yamada wrote: >>> 2015-11-13 14:43 GMT+09:00 Nishanth Menon <n...@ti.com>: >>>> Header files can be located in a generic location without >>>> needing to reference them with ../common/ >>>> >>>> Generated with the following script >>>> >>>> #!/bin/bash >>>> vendor=board/LaCie >>>> common=$vendor/common >>>> >>>> cfiles=`git grep "../common" $vendor|grep "#include"|cut -d '"' -f2|sort >>>> -u|grep c$` >>>> headers=`git grep "../common" $vendor|grep "#include"|cut -d '"' -f2|sort >>>> -u|grep h$` >>>> >>>> mkdir -p $common/include/board-common >>>> set -x >>>> for header in $headers >>>> do >>>> echo "processing $header in $common" >>>> hbase=`basename $header` >>>> git mv $common/$hbase $common/include/board-common >>>> sed -i -e "s/\"..\/common\/$hbase\"/<board-common\/$hbase>/g" >>>> $vendor/*/*.[chS] >>>> sed -i -e "s/\"$hbase\"/<board-common\/$hbase>/g" >>>> $vendor/common/*.[chS] >>>> done >>>> >>>> Cc: Simon Guinot <simon.gui...@sequanux.org> >>>> Cc: Albert ARIBAUD <albert.u.b...@aribaud.net> >>>> >>>> Signed-off-by: Nishanth Menon <n...@ti.com> >>>> --- >>> >>> >>> As far as I understood from 02 to 12, >>> the effect of this series is: >>> >>> either >>> replace "../common/foo.h" with <board-common/foo.h> >> for board/specific board files. >> >>> or >>> replace "bar.h" with <board-common/bar.h> >> yes - for board/common headers which are exposed. >> >>> >>> Vendor common headers are referenced within their own directory. >>> #include "..." is better than #include <...> in such cases. >> >> Not after this series, which is what is the 3rd change done by this >> series: The headers are moved to a common location away from the >> board/common directory. >> >> This is more inline with what you did with mach. >> >>> I still do not understand what problem this series wants to solve. >> >> standardize board common header inclusion strategy across boards in a >> consistent manner similar to what mach/ changes have been doing. >> >> Overall, you did mention in https://patchwork.ozlabs.org/patch/541068/ >> >> >> [step 1] move SoC-specific headers to arch/<arch>/mach-<soc>/include/mach >> >> [step 2] change #include <asm/arch/foo.h> to #include <mach/foo.h> >> >> >> >> Why did we not let folks user relative includes such as #include >> "../../mach/xyz.h" ? because it constraints us from changing the >> directory architecture in the future. >> >> This is exactly the same problem that board/<vendor>/ folders have. >> >> >> Why is it that you dont see that as a problem? >> > > > You are misunderstanding. > > SoC headers (either <asm/arch/*.h> in old style, or <mach/*.h> in new > style) are exported. > > > For example, arch/asm/include/asm/gpio.h includes <asm/arch/gpio.h>. > Also, many files under drivers/ include <asm/arch/*.h> > > I do not think any drivers should depend on SoC specific headers, > but it is the place where we stand now. > > > OTOH, vendor headers should be only referenced locally. > We should not expand the scope. No need to standardize the include path. > ^^^ > > Relative path is a correct way to include a header file with local scope. > > Even Linux does so. > > For example > > drivers/pinctrl/sunxi/pinctrl-sunxi.c >
Hmm... so, lets review our status currently: a) board/$(VENDOR)/board_X, board/$(VENDOR)/board_Y, board/$(VENDOR)/board_Z all need a common function, this is currently in board/$(VENDOR)/common/xyz.c. b) the function prototype for the function needs to be in xyz.h so that board/$(VENDOR)/board_[XYZ] can use the function. c) your suggestion is to stay in local scope for board/$(VENDOR)/board_[XYZ] by "../common/xyz.h" So much I have understood. I dont understand *why* you feel that vendor headers should only be referenced locally. Could you elaborate a little more on that? Is it because of the risk that drivers will now be able to do <board-common/xyz.h> ? If that is the case, and Tom, Simon, you folks agree as well, I can drop the entire series. -- Regards, Nishanth Menon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot