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

Re: [PATCH 20/37] xen: introduce CONFIG_EFI to stub API for non-EFI architecture



Hi,

On 27/01/2022 09:27, Jan Beulich wrote:
On 27.01.2022 10:25, Wei Chen wrote:
From: Jan Beulich <jbeulich@xxxxxxxx>
Sent: 2022年1月27日 17:17

On 27.01.2022 10:09, Wei Chen wrote:
From: Jan Beulich <jbeulich@xxxxxxxx>
Sent: 2022年1月27日 17:00

But you realize we already have such a stub file on x86?


Yes, we found the redefinition errors that are caused by x86 stub file
and new macros in stub.h. We had tries to add:
ifeq ($(XEN_BUILD_EFI),y)
CFLAGS-y += -DXEN_BUILD_EFI
XEN_CFLAGS += -DXEN_BUILD_EFI
endif
x86/Makefile to gate these new macros, but it seems that we may need
to change EFI build logic for x86. It will cause more risks for me.
So I want to introduce a similar stub.c in arch/arm.

While that's perhaps fine, ideally common bits would be common. Iirc
already back at the time I was wondering why stub.c had to be x86-
only.

Some dummy functions in stub.c can be shared by arm or other architectures.
But some functions like efi_multiboot2 are architecture dependent.

Right - that's no different from the bulk of the non-stubbed EFI code.
I don't really mind you making an Arm-specific stub file if there's
not very much duplication, but it doesn't feel very good. In the end
it's up to the Arm maintainers anyway.

If the stubs are mostly the same then they should be common rather than duplicated.

> x86/Makefile to gate these new macros, but it seems that we may need
> to change EFI build logic for x86. It will cause more risks for me.

But that would be a build risk right? If so, it is quite easy to verify/catch it compare to runtime issue.

Cheers,


Jan


--
Julien Grall



 


Rackspace

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