qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/5] softmmu templates: optionally pass CPUState


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH 2/5] softmmu templates: optionally pass CPUState to memory access functions
Date: Sat, 25 Aug 2012 09:52:54 +0000

On Fri, Aug 24, 2012 at 11:01 PM, Peter Maydell
<address@hidden> wrote:
> On 24 August 2012 19:43, Andreas Färber <address@hidden> wrote:
>> Depends on what you mean with "disable"? Adding an #error would hurt our
>> arm build just like earlier the ppc build, and I would hope from my last
>> testing that the problems would only affect the AREG0 targets,
>> especially not ARM on ARM (or MIPS on MIPS).
>>
>> Aborting at runtime, only when really unsupported, would seem better.
>>
>> I had taken a look at tcg/arm/ shortly after having fixed ppc (seeing
>> that there was a similar TODO or FIXME) but got distracted by other
>> projects. And your remarks wrt stack sound a bit frightening now. ;)
>> @Peter, have you looked into tcg/arm/ AREG0 support?
>
> Not yet. Why did we commit something that broke half our TCG
> targets and why don't we just back it out for 1.2 ?

Why didn't you all complain earlier? There was enough time to review
the patches and plenty of time after the commits to test QEMU and
report problems. Backing out now is impossible and also useless if
someone who cares enough for the hosts affected steps forward and
fixes the broken targets in the coming weeks.

It should be also possible to disable non-working TCG targets for 1.2
or as I proposed in other message, simply declare the situation in
release errata and see if anyone ever cares.

I'd seriously also question how beneficial it is for QEMU project to
drag along TCG target support for poorly maintained targets or any
less maintained feature. As a comparison, there's ever growing
pressure to break non-Linux target support (not so much on purpose),
but since we have active people who detect problems early (even before
committing with the help of build bots), report immediately and fix
the problems, for example Win32 and OpenBSD builds are fine today even
if they need considerable support from core code. Compared to that,
the TCG target situation is pretty bad, bordering hopeless, even
though there's much less pressure for change and they are nicely
isolated. Do we even know which targets work and which don't?

>
> -- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]