[SeaBIOS] [Qemu-devel] KVM call agenda for 2013-05-28

[Laszlo Ersek]

On 05/30/13 14:19, David Woodhouse wrote:

> Yeah, but if we're shoving a lot of hardware-specific ACPI table
> generation into the guest's firmware, instead of just doing it on the
> qemu side where a number of us seem to think it belongs, then there *is*
> a benefit to using Coreboot. When stuff changes on the qemu side and we
> have to update the table generation to match, you end up having to
> update just the Coreboot package, and *not* having to patch both SeaBIOS
> and OVMF.
> 
> The extra package in the distro really isn't painful to handle, and I
> suspect it would end up *reducing* the amount of work that we have to do
> to update. You update *just* Coreboot, not *both* of SeaBIOS and OVMF.

I can't deny there's logic in that, but it still feels like tying
ourselves up in some intricate bondage choreography. "We'd like to move
ACPI tables out of firmware, but we can't move them to qemu due to
project direction disagreement, so let's adopt a middleman." (I'm not
trying to denigrate coreboot -- I don't know it at all --, but
introducing it in a (granted, distro-specific) stack just for this
purpose seems quite arbitrary.)

>> If you implement a private UEFI FAT driver from scratch, or port a free
>> software FAT implementation (eg. the r/o one in grub or the r/w one in
>> mtools), you could still run into legal problems, I've been told.
> 
> That has been said, and it's been said for the FAT implementation in the
> kernel too. If a distribution is happy to ship the kernel without
> ripping out its FAT support, then I see no reason why that distribution
> wouldn't also be happy to ship a version of OVMF with a clean
> implementation of FAT support. It doesn't make sense to be happy with
> one but not the other.

Under my *personal* impression, logic and Common Law don't really mix,
especially not in the US. Still under my *personal* impression, someone
might not feel convenient suing you for redistributing code that already
exists in the upstream Linux kernel, but might happily drag you to court
for an original clean implementation, and then you can explain it's
illogical for them to do so.

The best I can do with your suggestion is to take it to our legal dept.
I would be happy to work on a new FAT driver. (I used to feel
differently earlier but I've changed my mind.)


>> We need at least one out-of-tree edk2 patch for now (from you) but
>> apparently that's no problem.
> 
> That'll get merged soon. We are working on the corresponding spec
> update...

Great news!

Thanks,
Laszlo