On 02/25/13 14:43, Peter Stuge wrote:
- Significant amounts of code can quite likely be shared between
many different hypervisors, since coreboot already shares significant code between many different hardware platforms, never mind the reuse possible across *both* hypervisors and hardware.
Not really. Virtual hardware can be reconfigured in ways which is impossible on real hardware. This is (party) where the complexity we have in seabios wrt. acpi comes from.
- 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.
I'm not convinced using coreboot is a clear win, especially with EFI coming. Can coreboot run tianocore as payload?
I understand that noone really cares about those arguments as long as I don't do their work for them,
If using coreboot would be a clear and obvious win someone would have done that work already.
ACPI not working at all in linux guests when using coreboot with seabios payload doesn't exactly encourage exploring that option btw.
but I'm afraid I will not stop complaining as long as SeaBIOS grows with more and more stuff that has nothing to do with a BIOS environment but has to do with lower level platform init.
Well, *this* discussion is about moving stuff *out* of seabios.
Maybe someday someone will actually get the point..
I figured long ago which point you are trying to make. I don't agree though.
cheers, Gerd