[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN PATCH v7 42/51] build: grab common EFI source files in arch specific dir


  • To: Anthony PERARD <anthony.perard@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 21 Oct 2021 13:24:27 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=28n5/3JGSx05ZTYkCn1qgK/UejdJp4oaBAIggQEUfwU=; b=kU8OshWG9PvWHKHEhIYFYm3T5pH4kZg2It0f0yr6cjU5OVbjLKRx1UCg+hAU6FkQwE8OAkdeVHjtJuNVPAFA0rGs6qWv0huX6rJA4SLXQQD5YjnnQ/kiDLr3i5ZN7xA4HXmm48H0AHC8EfVM3doxdWNkRle+dsTY/GQ4vN6KrciKH9PK9qyBzHxetDm/xwe+cXr1Nb4gHwVJc2EtDzHvbu2uqJ5I8IkB4w3X3Aq7hjteMxPy5VSUnqB6aCNw+shvQSPebXeb1lPzpa9hAhirHx7MZO3RBJoSmMgWtOdJLoicxJ7suF1uymdJPHeiDRHdOkiLjjUjM2Wr1Yj144qzZQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LVFIH6WteekwIKFBrSdvN6cGstJHdllkwOh6izis+tiJ7sqZ05rCoSazADi2yEJF8f45gWeCCxPlnVSUh4uTP4r/yDGg1rePksbGfdnHJ4q6VbGd+LAZdHGmntmzn7R4zEALfs46vt88Z/m+CbIEW/yTdWVA+Y1spJLoZyJgiQ5pozgk+5cSBcSw6hX9tMmPlsKLUwzXyM0kg0SBYk79dTidKepMqxduoyC9oYSKHXYQMDPz97XbbwzooVlhVNWPc/fnMn9JLVhVZVHWUtuZbE7fgNZ8Rjgoswe7UXuDsGd/CdsMBnSDVlkzdQSEGpgSnXnfkZjlAV01n9cWcz0guQ==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 21 Oct 2021 11:24:47 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 21.10.2021 13:03, Anthony PERARD wrote:
> On Mon, Oct 18, 2021 at 10:48:26AM +0200, Jan Beulich wrote:
>> On 15.10.2021 18:29, Anthony PERARD wrote:
>>> On Thu, Oct 14, 2021 at 10:51:44AM +0200, Jan Beulich wrote:
>>>> On 24.08.2021 12:50, Anthony PERARD wrote:
>>>>> --- a/xen/arch/arm/efi/Makefile
>>>>> +++ b/xen/arch/arm/efi/Makefile
>>>>> @@ -1,4 +1,10 @@
>>>>>  CFLAGS-y += -fshort-wchar
>>>>> +CFLAGS-y += -I$(srctree)/common/efi
>>>>
>>>> Perhaps another opportunity for -iquote?
>>>
>>> Yes.
>>>
>>>>>  obj-y += boot.init.o pe.init.o ebmalloc.o runtime.o
>>>>>  obj-$(CONFIG_ACPI) +=  efi-dom0.init.o
>>>>> +
>>>>> +$(obj)/%.c: common/efi/%.c
>>>>> + $(Q)cp -f $< $@
>>>>
>>>> In case both trees are on the same file system, trying to hardlink first
>>>> would seem desirable. When copying, I think you should also pass -p.
>>>
>>> I don't know if doing an hardlink is a good thing to do, I'm not sure of
>>> the kind of issue this could bring. As for -p, I don't think it's a good
>>> idea to copy the mode, ownership, and timestamps of the source file, I'd
>>> rather have the timestamps that Make expect, e.i. "now".
>>
>> Why would "now" be correct (or expected) in any way? The cloned file is no
>> different from the original. Nevertheless I agree that -p is not ideal;
>> it's just that the more fine grained option to preserve just the timestamp
>> is non-standard afaik. You could try that first and fall back to -p ...
>> Otherwise, failing hard linking and using "cp -p", I'm afraid I'd prefer
>> symlinking despite the arguments against it that you name in the
>> description.
> 
> I guess I'm missing something, is there a reason to keep/copy the
> timestamps of the original files?

Avoidance of confusion is my main aim here. I certainly would be puzzled
to see what looks like a source file to have a time stamp much newer than
expected.

Jan




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.