On Mon, 2013-02-25 at 15:46 +0100, Gerd Hoffmann wrote:
> 
> > 2. Having (many!) hypervisor-specific special cases in SeaBIOS seems
> > wildly schizophrenic without bringing any significant benefits,
> > compared to factoring all of that out into a codebase which *already
> > does many of the needed things*.
> 
> It's a tradeoff.  On one hand letting coreboot handle hardware
> initialialization would reduce the amout of code in seabios we have to
> maintain.  On the other hand adding coreboot as middle man between qemu
> and seabios would add some complexity to the whole mix.

But if we do it *without* coreboot, then we get to reimplement the whole
"seabios-qemu-seabios ping-pong", as Laszlo describes it, in Tianocore
as *well* as SeaBIOS. I'm not sure we really want to duplicate that
code, which looks like it will have tricky interactions between host and
guest. When viewed that way, it's not clear that doing it in coreboot is
really adding complexity; in that respect it *simplifies* things a bit.

Using coreboot everywhere sounds good to me. Especially because on the
Tianocore side we can push for Patrick's CorebootPkg to be the *primary*
platform; we could even consider deprecating the qemu-specific OvmfPkg
completely. And *that* in turn ensures that what everyone's working on
is something that ought to be suitable for real hardware, rather than
just qemu.

It would also help some people on the UEFI side to get over their
bizarre misconception that coreboot is antithetical to UEFI :)

I'd be quite happy to get to the point where the default firmware for
Qemu is Coreboot + Tianocore + SeaBIOS (as CSM).

-- 
dwmw2

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

_______________________________________________
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Reply via email to