On Friday 27 March 2009 13:59:36 Blue Swirl wrote:
On 3/25/09, Rob Landley rob@landley.net wrote:
On Sunday 22 March 2009 11:54:22 Blue Swirl wrote:
So the bug was introduced (or at least triggered) by revision 452:
http://tracker.coreboot.org/trac/openbios/changeset/452/openbios-dev el
Anything in there look broken to you?
Fixed in r481. I removed the PCI encode-unit/decode-unit methods for non-bus devices, now get-instance-path works.
Cool!
Is there a procedure to ask how to queue this up for qemu 0.10.2? :)
Technically the best solution would be to introduce a stable tree also to OpenBIOS like Qemu. But OpenBIOS development is not as fast paced as Qemu, so I'm not sure if it's worth the effort.
I can commit the latest version to Qemu SVN and if there are no issues, update the version in stable before release.
Rob
(By the way: qemu is shipping a gpled bios binary without accompanying source code. I realize that the maintainer of said binary checked it in, but what exactly is the rationale here?)
I see it as a service for both OpenBIOS and Qemu development communities, also the casual users don't have to install cross compilers just to try the Sparc/PPC emulators. The binaries are compiled from unmodified sources as indicated in the README.
If someone finds problems with this, it's easy to put the binaries to OpenBIOS site and remove them from Qemu SVN. That would make bisecting a bit harder. Or Qemu could just include the OpenBIOS tree, it's only 12M.
I'm not complaining, I just tend to pay attention to license issues.
If qemu is never going to try to enforce its license, it probably doesn't matter. If it _does_ and the other side can point to you guys not honoring your own license terms, you may have a hard time getting them to.
Most likely you guys fall under GPLv2 section 3c anyway. Commercial redistributors of qemu might have to include the openbios source in addition to the qemu source (and maybe the bochs bios source, who knows?) But the qemu project itself probably doesn't.
Rob