2015-11-15 14:38 GMT+09:00 Nishanth Menon nm@ti.com:
On 11/14/2015 05:56 PM, Masahiro Yamada wrote:
2015-11-13 14:43 GMT+09:00 Nishanth Menon nm@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.guinot@sequanux.org Cc: Albert ARIBAUD albert.u.boot@aribaud.net
Signed-off-by: Nishanth Menon nm@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