[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |