[SeaBIOS] [PATCH] qemu: piix: PCI bridge ACPI hotplug support

[Anthony Liguori]

Hi Jordan,

On Mon, Jun 10, 2013 at 7:28 PM, Jordan Justen <jljusten at gmail.com> wrote:
> On Mon, Jun 10, 2013 at 2:45 PM, Anthony Liguori <anthony at codemonkey.ws> wrote:
>> OVMF is proprietary.
>
> I don't agree that not-OSI means proprietary.

I call it blue if that makes you all feel better :-)  But no matter
what the word we use it, the point still stands, we need a UEFI
firmware that has a OSI-approved license.  Forgetting everything else,
the distros can't ship OVMF in its current form.

> I agree that the FAT driver is not 'free software' and I agree that is
> a problem for usage with free software projects, such as QEMU. This is
> a big deal, but unfortunately, as an Intel employee, I think I've done
> as much as I can to address this.
>
> It couldn't hurt if more people that actually care about this spoke up
> on edk2-devel about the issue, or perhaps within a UEFI working group.
> Because, I know that they've stopped listening to me about it.

Is this useful?  I can try to make noise.  I assume since folks like
you who have much more credibility and familiarity in this space have
given up, it's a lost cause.

>> It is not "supported" by QEMU.
>
> No, but I've always thought that QEMU was happy to have alternative
> firmware projects.

We are and we're happy to accept patches to enable things even if its
proprietary.  But that's all assuming we're improving hardware
emulation.

What we're talking about here is doing something that's very un-hardware like.

>> I'm not really convinced that
>> QEMU<->firmware is a GPL boundary because of how tightly the two are
>> linked.
>
> Where has 'linked' in terms of the GPL ever been anything other than
> actual executable linking?

I should not have even brought this up as it's not worth debating.  If
you're curious,
http://www.gnu.org/licenses/gpl-faq.html#MereAggregation

>> Moving large chunks of firmware code into QEMU just to avoid solving
>> licensing issues is a non-starter with me.
>
> Is this a licensing issue? I thought this was a "let's save time by
> doing it in one place" thing. I'm pretty ambivalent about this
> feature, really. I don't think it is even worth all this bickering.
>
> I'm certain OVMF has ACPI issues on QEMU, but I don't think it is a
> huge deal to resolve them independently of this feature.

Doing it one place could just mean share code.  Code can't be shared
today, that's why licensing has come up.

Regards,

Anthony Liguori

> I was not a huge fan of supporting this type of thing for Xen in OVMF,
> but it does seem to work fine.
>
> -Jordan