[Buildroot] [PATCH] linux: handle read-only dts files

[Hollis Blanchard <hollis_blanchard@mentor.com>]

On 08/12/2015 09:11 AM, Nikolay Dimitrov wrote:
> Hi Hollis,
>
> On 08/12/2015 07:02 PM, Hollis Blanchard wrote:
>> The DTS exists at $(BR2_LINUX_KERNEL_CUSTOM_DTS_PATH) because that's
>> where it lives. It's copied to $(KERNEL_ARCH_PATH)/boot/dts/ so that the
>> kernel build process can build a DTB out of it (which is later copied to
>> build/images/).
>>
>> Or did I misunderstand the question?

(Just to be clear: $(BR2_LINUX_KERNEL_CUSTOM_DTS_PATH) is under version 
control, while $(KERNEL_ARCH_PATH), the build directory, is not.)

> Sorry, I could've been probably more clear. My question was whether the
> DTS needs to exist also at the destination ($(KERNEL_ARCH_PATH)/boot
> /dts/) before the copying happens.

It does not need to exist there. It's only there because of a previous 
cp in a previous build.

> If it doesn't exist at the destination, the VCS wouldn't have checked
> it out as r/o file, and the issue wouldn't happen in the first place
> (e.g. the copy operation will succeed). Also, when we have 2 files with
> the same name and content, this tends to create confusion with
> developers (aka which file was the primary one).

The file needs to exist at the destination at least temporarily, for the 
DTS->DTB translation. You could say "we should remove it afterwards", 
but a) that could be technically difficult in the face of ^C and kill 
-9, and b) you could say the same about zImage, vmlinux, etc... so we'd 
really be talking about a full "make clean", which seems like overkill.

Are you suggesting "rm -f; cp" instead of "cp -f"? As far as I know the 
two are functionally equivalent, so the former seems like slightly more 
overhead to get the same effect as the latter.

cp -f seems a simple solution: try harder to copy the file. :-)

Hollis Blanchard
Mentor Graphics Emulation Division