[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 Julien, > -----Original Message----- > From: Julien Grall <julien@xxxxxxx> > Sent: 2022年1月27日 18:01 > To: Jan Beulich <jbeulich@xxxxxxxx>; Wei Chen <Wei.Chen@xxxxxxx> > Cc: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>; xen- > devel@xxxxxxxxxxxxxxxxxxxx; sstabellini@xxxxxxxxxx > Subject: 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. > Risk may be not very accurate word. I mean, I was afraid that my changes to x86 EFI build would introduce some unforeseen problems to x86. Because I am not very familiar with that. As you and Jan think it's better, I will try to do it. > Cheers, > > > > > Jan > > > > -- > Julien Grall
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |