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

[Nishanth Menon <nm@ti.com>]

On 11/15/2015 09:32 PM, Masahiro Yamada wrote:
> 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
> 

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