When are Qemu SPARC/PPC coming back?

Nathaniel McCallum nathaniel at natemccallum.com
Thu Sep 15 01:19:18 UTC 2011


On Wed, Sep 14, 2011 at 9:12 PM, Josh Boyer <jwboyer at gmail.com> wrote:
> On Wed, Sep 14, 2011 at 8:45 PM, Nathaniel McCallum
> <nathaniel at natemccallum.com> wrote:
>> On Wed, Sep 14, 2011 at 8:13 PM, Josh Boyer <jwboyer at gmail.com> wrote:
>>> On Wed, Sep 14, 2011 at 7:29 PM, Nathaniel McCallum
>>> <nathaniel at natemccallum.com> wrote:
>>>> The context for this question can be found here:
>>>> http://lists.fedoraproject.org/pipermail/virt-maint/2011-March/002289.html
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=679179
>>>
>>>> What I'm not fine with is that there seems to be no desire to bring
>>>> these packages back. I spoke with several Red Hat virt people and the
>>>> consensus was that SPARC/PPC "don't work." I beg to differ. I am
>>>> building asm software on them right now. They are an invaluable
>>>> software testing platform, even with their relative age.
>>>>
>>>> So in short, can we please bring back SPARC/PPC? I realize that we'll
>>>> need a bit of build system magickery, but I really think its worth it.
>>>
>>> No.  Not magickery.  Basically, it needs a build-able openbios or SLOF
>>> (in the ppc case).  And since Fedora doesn't provide cross
>>> compilation, that is going to be hard to do in this case.
>>>
>>> As I see it, there is likely one option.  It is possible that we
>>> leverage the secondary architecture builders for PPC and SPARC and
>>> natively build the code, then allow an exception for i686/x86_64
>>> packages to use that natively built openbios/slof.  It would need
>>> FESCo approval, but exceptions for bootstrapping have been granted
>>> before.
>>>
>>> All of this is predicated on someone stepping forward to do the work.
>>> So far, we've found people that don't want to do the work but we need
>>> to work the opposite angle.
>>
>> "No. Not magickery. ... Fedora doesn't provide cross compilation ..."
>>
>> How is this not magickery? Heck, even the build them natively and
>> allow other arches to use them is magickery...
>
> Not it's not.  You build them as noarch.  It's not magic at all.
>
>> Of course, there is a second option, and one that require far less
>> work: use the binaries that qemu provides. Yes, I know its evil and
>> all that (and I agree). Except that in this case the binaries are made
>> form open code that's just hard to build (and absent investment in
>> infrastructure, won't get any easier) and for which upstream already
>> does the hard work. Further these binary firmwares are actually
>> running in an emulator and as such the possible damage is approaching
>> 0. Will it be harder to debug? Maybe, but I doubt it. In fact, you
>> could make an argument that shipping the upstream bios builds is the
>> best way to get upstream support for our build.
>
> You could try and get an exception from FESCo for that, yes.  I'm not
> sure it would be approved until someone actually tries building them
> first.

Care to walk me through the process?


More information about the devel mailing list