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: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH 2/5] softmmu templates: optionally pass CPUState to memory access functions
Date: Thu, 20 Sep 2012 13:46:58 +0200

On 25.08.2012, at 11:52, Blue Swirl wrote:

> 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?

I would think the same approach we have with the built bots should work quite 
well here. If as part of the build bot builds, we also had smoke execution 
tests, we would catch a lot of problems early on.

In fact, I can even donate an IA64 box as build bot as soon as we have such a 
system in place.


Alex




reply via email to

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