[Buildroot] [PATCH] linux: handle read-only dts files
Hollis Blanchard
hollis_blanchard at mentor.com
Wed Aug 12 16:27:18 UTC 2015
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
More information about the buildroot
mailing list