On Wed, 26 Mar, at 03:02:17PM, Daniel Kiper wrote: > On Wed, Mar 26, 2014 at 12:56:23PM +0000, Matt Fleming wrote: > > > > Please don't create another struct of EFI function pointers. > > > > After this we'll have 3 global efi structures defintions and 4 global > > efi objects on x86, > > > > - struct efi_early [in the boot stub] > > - struct efi ['efi_phys' before/'efi' after SetVirtualAddressMap()] > > - struct efi_init_ops [for the benefit of xen] > > What do you suggest? Should we fill all EFI related structures > in xen_efi_probe() (called from xen_start_kernel()) and later > they should be parsed by generic/x86 EFI initialization code? > I suppose that many variables will have NULL (or something relevant) > in Xen dom0 and it will require some changes in EFI initialization code. Yeah, that is what I was thinking. And if we have to make some changes to the generic code to accomodate NULL fields, etc, I don't think it's a big deal. > > I have a big problem with exposing .efi_reserve_boot_services as an API. > > Why? efi_reserve_boot_services() is public right now. Sure it's public, but it isn't implemented on ia64 at all, not even as a stub function, and it's only called inside x86 code (the fact that the prototype is in include/linux/efi.h is a bit of a bug). My concern is that if in we bake into our APIs it's going to be difficult in the future to get rid of it or disable it, or at least allow people to write code for EFI without caring about it. Afterall, it's a workaround for buggy firmware. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
