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

Re: [XEN PATCH] build: Fix x86 build without EFI


  • To: Julien Grall <julien@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 19 Aug 2022 07:53:21 +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=/6AAXfDiAxXArGsZ5/ZfYH+rztlsh5AM94IBUfkijVE=; b=blKgBBt28B8V7RnyQDX+CchgvHqrnJXZuvGXSOG8XwBx//s6E8cG73FzK6gjke5764x89BJjA25d9PTZcvsX7bW179BMI4o8RpkbVRHryEMEzsPyc4QF/RmIsfI+x3TQaN5kFx5KaADovICsGomhb5O/hOrleOirdswZTOje0DJXz3xCETgFEmg24wSgqNUTItt+IR3NBCol8WlskoNm91Rfp0RRtt6/P1XdP1wmtCPKUoPC9HZSy+LWYi6oDNKMnptsbY2FABg6whNeCB0QkZhHhyJf03l1PSYP0w7JzekmIY9PjbZUTE/eu/4sho94qW853VB7KGHrN3K8LTt7bA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jUMgS2bcEYJpcFNeRjOHxUwsMXb1BhsmocxOP20NXm8fCbKmLmi5sG4d+iCNDOiKhQB7/X+xH/abP53W0svpop+OL8eiYu27SwfeLcmOdQWMkbY4xjQOCh3imvN0sPCgDhygxScCPRaEySGDwG9p6hL3NqUutwFu4G50tKd4nSQrpFoeYLd0S2rC/7tWbsTihlji9bjyjee1NHJtELqfcVO42LxDlJddULPx1jyoGWdmaMtRe7cpWwREfEQPbOBkf+DPhqXYM5lmRefyZTn7BLWOmOluE/ncdtOiid/PHWcswqB/2LA2fcpfjUllZMTl/yNOQPuiuE6Gi4cGeeGcug==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Wei Chen <wei.chen@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 19 Aug 2022 05:53:42 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 18.08.2022 19:42, Julien Grall wrote:
> On 16/08/2022 17:29, Jan Beulich wrote:
>> On 16.08.2022 17:43, Anthony PERARD wrote:
>>> On Tue, Aug 16, 2022 at 03:02:10PM +0200, Jan Beulich wrote:
>>>> On 16.08.2022 12:30, Anthony PERARD wrote:
>>>>> We can't have a source file with the same name that exist in both the
>>>>> common code and in the arch specific code for efi/. This can lead to
>>>>> comfusion in make and it can pick up the wrong source file. This issue
>>>>> lead to a failure to build a pv-shim for x86 out-of-tree, as this is
>>>>> one example of an x86 build using the efi/stub.c.
>>>>>
>>>>> The issue is that in out-of-tree, make might find x86/efi/stub.c via
>>>>> VPATH, but as the target needs to be rebuilt due to FORCE, make
>>>>> actually avoid changing the source tree and rebuilt the target with
>>>>> VPATH ignored, so $@ lead to the build tree where "stub.c" dosen't
>>>>> exist yet so a link is made to "common/stub.c".
>>>>>
>>>>> Rework the new common/stub.c file to have a different name than the
>>>>> already existing one. And build both *stub.c as two different objects.
>>>>> This mean we have to move some efi_compat_* aliases which are probably
>>>>> useless for Arm.
>>>>
>>>> These useless aliases want avoiding there imo. Already when the original
>>>> series was discussed, I requested to avoid introduction of a file named
>>>> common-stub.c or alike.
>>>
>>> Yeah, I've notice that. This is why the build is broken under
>>> specific condition.
>>>
>>>> If names need to be different, can't we follow
>>>> boot.c's model and introduce a per-arch efi/stub.h which stub.c would
>>>> include at a suitable position (and which right now would be empty for
>>>> Arm)?
>>>
>>> That seems to be possible. But how is it better than having two
>>> different source file? The only thing is to avoid exporting the
>>> efi_compat_* symbol aliases.
>>
>> As said - I think they're wrong to have in Arm. But if Arm maintainers
>> don't care about them being there, so be it. As long as they don't
>> voice a view, I guess as the EFI maintainer I can sensibly ask for
>> them to be avoided in a reasonably clean way.
> 
> AFAIU, the two aliases are using by the compat code. So how about 
> protecting it with CONFIG_COMPAT (like we do for other compat code in 
> common code)?

Hmm, yes, that ought to work.

Jan



 


Rackspace

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