On Tue, 17 Jun 2008 22:58:00 -0400, Kevin O'Connor kevin@koconnor.net wrote:
On Tue, Jun 17, 2008 at 09:25:59PM -0400, Joseph Smith wrote:
On Wed, 18 Jun 2008 01:04:49 +0200, Stefan Reinauer
wrote:
To make this really good, we'd need to heavily extend that intXX callback code in coreboot. Which means it has to grow and grow and it will eventually become a reduced version of LegacyBIOS. That is bad.
If
we know LegacyBIOS does a pretty good job and it is reasonably small (even qemu's current bios.bin is under 30k with , I would really
prefer
using it for that task instead of yet another half-baked solution.
I think we all came to an agreement that the only "real" way to do this
is
integrate legacybios (or parts) into coreboot (as an option of course).
I recommend caution here.
I think it is important that LegacyBIOS support kvm, qemu, and bochs. Having the code support those environments will help increase the overall user base, which will help ensure the core code supports many different OSes and is thoroughly tested. So, I don't think we want to make LegacyBIOS coreboot specific.
I also don't think it would be a good idea to fork the code or copy large parts of it into multiple repositories.
So, I'm all for aligning coreboot and LegacyBIOS - it is after all the reason I started LegacyBIOS - but I think we need to come up with a boundary between the two. In my opinion, coreboot should (optionally) call out to LegacyBIOS and the two should work towards the same goal. But I don't think they should be tightly integrated at the source code level.
Hmm. Then how are we going to go about this? What do you suggest Kevin? Could we set up coreboot to call LegacyBIOS at a certain point, execute it, and then jump back to coreboot? Kind of like vm86/x86emu does for VGA? If so at what point in the coreboot process do we want this to happen?