On 09/19/2013 03:53 PM, Chris Murphy wrote: > > On Sep 19, 2013, at 8:56 AM, Eric Blake <eblake@xxxxxxxxxx> wrote: >> >> Given the current state of the art, all known UEFI implementations for >> VMs require the use of a FAT driver whose license forbids redistribution >> for general purpose use, which means Fedora cannot ship it. > > I don't understand this. > > First, there is already a FAT driver that works out of the box in Fedora for general purpose use. The kernel FAT driver is GPL. But state of the art for UEFI is the OVMF code base, which is mostly BSD, but contains a non-open FAT driver. Meanwhile, the OVMF folks have explicitly stated they are unwilling to incorporate GPL code (which would make their entire project GPL, and cut them off from proprietary vendors that currently rely on the looseness of BSD licensing). So far, no one has forked the open portions of OVMF to mix in an alternative FAT module (such as providing a GPL UEFI solution by reusing the kernel's fat driver), and as no other VM boot loader code understands UEFI (Fedora ships SeaBIOS, but that is BIOS not UEFI), then there is currently no way to boot a VM under UEFI while still being able to distribute that loader in Fedora. > > And second, the UEFI spec in section 12.3 considers the EFI file system to be distinct from, although based on, FAT. And the spec includes long file name support, using UCS-2 encoding. Microsoft only have patent claims on FAT that relate to long file names. This is in effect not Microsoft's FAT, but rather an EFI file system maintained by the UEFI spec and is unchanging from Microsoft FAT variants. > > We probably ought to have a mkfs variant for ESP's to ensure it's created per the UEFI spec and is guaranteed to not evolve with mkdosfs|mkfs.msdos|mkfs.vfat. What the kernel FAT drivers do is independent of what a VM loader has to be able to do to emulate UEFI to the guest. Although you are probably right that the kernel folks should take care that their UEFI interactions don't break, that is independent of the licensing issue at hand for VM booting. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test