On Thu, Dec 01, 2016 at 03:25:29PM -0700, dann frazier wrote:
> My reasons for choosing "qemu-efi" when adding the aa64 images were
> twofold:
> 1) "OVMF", in upstream source, refers only to the x86-specific
> build. The ARM images have always had a different name - initially
> ArmVirtualizationQemu, and currently ArmVirt.
> 2) "OVMF" doesn't seem like a keyword users would likely be familiar
> with. I'd expect a user to know they want "EFI" or "UEFI" for use
> with QEMU. OVMF, IMO, is yet another obscure term in the soup of
> names here (edk2, EFI, UEFI, Tianocore, OVMF).
>
> Therefore, if we're going to try for more consistent package naming, I
> think I'd rather not consolidate under "ovmf". Since, AFAIK, these
> images are only useful for QEMU models, I'd rather go the other way
> and use the "qemu-efi" stem instead of "ovmf", e.g.:
> qemu-efi-{aa32,aa64,ia32,x64}-virt
Feedback in #857858 led me to reconsider this. I'd like to amend
this proposal to use package names:
qemu-efi-{aarch64,arm,i386,x86-64}
This follows the convention used by the QEMU binaries:
qemu-system-{aarch64,arm,i386,x86_64}
This also drops the "-virt" stem, which now seems unnecessary.
> As for file paths, we're currently using the paths that libvirt and
> OpenStack nova default to. We could move everything and provide
> symlinks for compat, but I'm not convinced this is a big enough
> problem to do so - in fact, I think that would only add confusion.
> That said, libvirt/OpenStack don't appear to have unique paths defined
> for 32-bit variants, so I'm not sure what to do for those.
For 32-bit ARM, I propose we use:
/usr/share/AAVMF/AAVMF32_{CODE,VARS}.fd
Similary, for 32-bit x86, I propose:
/usr/share/OVMF/OVMF32_{CODE,VARS}.fd
-dann
