[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Woodhouse
Subject: Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28
Date: Thu, 30 May 2013 13:19:18 +0100

On Thu, 2013-05-30 at 13:13 +0200, Laszlo Ersek wrote:
> Where is CorebootPkg available from?


> > And it helps to dispel the stupid misconception in some quarters that
> > Coreboot *competes* with UEFI and thus cannot possibly be supported
> > because helping something that competes with UEFI would be bad.
> I'm not sure who do you mean by "some quarters", but for some
> distributions Coreboot would be yet another component (package) to
> support, for no obvious benefit.
> (Gerd said it better than I possibly could:
> <http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/5685/focus=5705>.)

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.

> 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.

> 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

> As far as I understand:
> - Jordan is nearing completion of flash support on KVM,
> - he also has WIP NvVar storage on top of qemu flash.
> http://thread.gmane.org/gmane.comp.emulators.qemu/213690
> http://thread.gmane.org/gmane.comp.bios.tianocore.devel/2781/focus=2798
> ("Please coordinate" I guess :))

Ooh, shiny. Yeah, when I get back to actually working on it rather than
just heckling, I'll make sure I do :)


Attachment: smime.p7s
Description: S/MIME cryptographic signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]