[U-Boot] [PATCH V2 07/12] board: LaCie: Move common headers to board-common directory

[Masahiro Yamada]

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






-- 
Best Regards
Masahiro Yamada