On 07/04/17 00:43, dann frazier wrote:
Hi Dann,
> I've done some initial work to generate Arm images, but there's some
> bikeshedding to do before it's ready to upload.
>
> Is there a consensus on a prefix for the Arm "VMF" images? OpenStack
> Nova hardcodes "/usr/share/AAVMF/AAVMF_CODE.fd" for AArch64, but it
> doesn't have Arm support yet apparently.
>
> Is there any need for the QEMU_EFI.fd artifact on ARM? We deliver both
> the QEMU_EFI.fd and AAVMF images for AArch64, but I don't know if anyone
> uses the QEMU_EFI.fd images themselves, and I'd rather not continue
> delivering the same code twice.
Agreed, having both is at best confusing. My own scripts are using
QEMU_EFI.fd (because that's the name that the EDKII build system uses),
but if there's a consistent use of AAVMF for the arm64 version, that's
fine by me.
As for the name of the 32bit version, I don't care much. AAVMF32_CODE.fd
would work for me.
> Finally, I think when we start adding new images (Arm/32-bit), we
> should do so under a cleaner packaging layout. See #842690 for a
> proposal there.
I'm being allergic to aa32 and aa64:
- If we're describing the execution mode, that should be AArch32/64.
- If we want something that people actually understand, that should be
arm/arm64.
But that's bikeshedding, and I don't have a strong opinion.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
