[Qemu-devel] qemu-1.0-rc1 delayed (need fix for PPC32 build)

[Qemu-devel] qemu-1.0-rc1 delayed (need fix for PPC32 build)

[Anthony Liguori]

Hi,

I was hoping we'd have a solution by now but it looks like we don't.  I'm going 
to delay the qemu-1.0-rc1 release until tomorrow.  I'd like to propose a couple 
paths forward.  Here's my understanding of the situation:

1) TCG changes were made for the Sparc/Alpha targets that use AREG0

2) AREG0 never worked properly on ppc32 hosts

3) Until recently, this caused a runtime failure of the Sparc/Alpha targets on 
ppc32.  However, malc recently changed this to a build time failure.

I don't feel comfortable shipping a release candidate with a known failing 
build.  Here are the options:

a) Revert malc's change.  I don't think this is much better than shipping a 
broken build.

b) Disable sparc/alpha targets in default_target_list on ppc32 hosts.  I think 
is probably the best short term approach.

c) Wait for Andreas' patches (I believe Alex detected a problem in the current 
version).

Unless anyone strongly objects, I'm going to implement (b) tomorrow morning so 
we can keep the -rc cycle moving.  I would hope that we'll have something worked 
out for (c) by -rc2.

Regards,

Anthony Liguori

Re: [Qemu-devel] qemu-1.0-rc1 delayed (need fix for PPC32 build)

[malc]

On Tue, 8 May 2012, Anthony Liguori wrote:

> Hi,
> 
> I was hoping we'd have a solution by now but it looks like we don't.  I'm
> going to delay the qemu-1.0-rc1 release until tomorrow.  I'd like to propose a
> couple paths forward.  Here's my understanding of the situation:
> 
> 1) TCG changes were made for the Sparc/Alpha targets that use AREG0
> 
> 2) AREG0 never worked properly on ppc32 hosts
> 
> 3) Until recently, this caused a runtime failure of the Sparc/Alpha targets on
> ppc32.  However, malc recently changed this to a build time failure.
> 
> I don't feel comfortable shipping a release candidate with a known failing
> build.  Here are the options:
> 
> a) Revert malc's change.  I don't think this is much better than shipping a
> broken build.
> 
> b) Disable sparc/alpha targets in default_target_list on ppc32 hosts.  I think
> is probably the best short term approach.
> 
> c) Wait for Andreas' patches (I believe Alex detected a problem in the current
> version).
> 
> Unless anyone strongly objects, I'm going to implement (b) tomorrow morning so
> we can keep the -rc cycle moving.  I would hope that we'll have something
> worked out for (c) by -rc2.
> 

I have no probelm with this, apart from rather shady definition of
tomorow.

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] qemu-1.0-rc1 delayed (need fix for PPC32 build)

[Artyom Tarasenko]

On Wed, May 9, 2012 at 3:52 AM, Anthony Liguori <aliguori@us.ibm.com> wrote:
> Hi,
>
> I was hoping we'd have a solution by now but it looks like we don't.  I'm
> going to delay the qemu-1.0-rc1 release until tomorrow.

[nitpicking] qemu-1.1-rc1 ?

> I'd like to propose
> a couple paths forward.  Here's my understanding of the situation:
>
> 1) TCG changes were made for the Sparc/Alpha targets that use AREG0
>
> 2) AREG0 never worked properly on ppc32 hosts
>
> 3) Until recently, this caused a runtime failure of the Sparc/Alpha targets
> on ppc32.  However, malc recently changed this to a build time failure.
>
> I don't feel comfortable shipping a release candidate with a known failing
> build.  Here are the options:
>
> a) Revert malc's change.  I don't think this is much better than shipping a
> broken build.
>
> b) Disable sparc/alpha targets in default_target_list on ppc32 hosts.  I
> think is probably the best short term approach.
>
> c) Wait for Andreas' patches (I believe Alex detected a problem in the
> current version).
>
> Unless anyone strongly objects, I'm going to implement (b) tomorrow morning
> so we can keep the -rc cycle moving.  I would hope that we'll have something
> worked out for (c) by -rc2.
>
> Regards,
>
> Anthony Liguori
>
>



-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu