From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nishanth Menon Date: Mon, 16 Nov 2015 09:34:07 -0600 Subject: [U-Boot] [PATCH V2 07/12] board: LaCie: Move common headers to board-common directory In-Reply-To: References: <1447393422-4169-1-git-send-email-nm@ti.com> <1447393422-4169-8-git-send-email-nm@ti.com> <56481A5A.9060509@ti.com> Message-ID: <5649F76F.6040702@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 11/15/2015 09:32 PM, Masahiro Yamada wrote: > 2015-11-15 14:38 GMT+09:00 Nishanth Menon : >> On 11/14/2015 05:56 PM, Masahiro Yamada wrote: >>> 2015-11-13 14:43 GMT+09:00 Nishanth Menon : >>>> 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\"//g" $vendor/*/*.[chS] >>>> sed -i -e "s/\"$hbase\"//g" $vendor/common/*.[chS] >>>> done >>>> >>>> Cc: Simon Guinot >>>> Cc: Albert ARIBAUD >>>> >>>> Signed-off-by: Nishanth Menon >>>> --- >>> >>> >>> As far as I understood from 02 to 12, >>> the effect of this series is: >>> >>> either >>> replace "../common/foo.h" with >> for board/specific board files. >> >>> or >>> replace "bar.h" with >> 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//mach-/include/mach >> >> [step 2] change #include to #include >> >> >> >> 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// folders have. >> >> >> Why is it that you dont see that as a problem? >> > > > You are misunderstanding. > > SoC headers (either in old style, or in new > style) are exported. > > > For example, arch/asm/include/asm/gpio.h includes . > Also, many files under drivers/ include > > 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 ? If that is the case, and Tom, Simon, you folks agree as well, I can drop the entire series. -- Regards, Nishanth Menon