[Top][All Lists]

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

Re: [Qemu-devel] [RFC v4 5/9] configure: Enable/disable new qemu_{ld, st

From: Aurelien Jarno
Subject: Re: [Qemu-devel] [RFC v4 5/9] configure: Enable/disable new qemu_{ld, st} excl insns
Date: Sun, 9 Aug 2015 10:40:20 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

On 2015-08-09 09:11, Alex Bennée wrote:
> Aurelien Jarno <address@hidden> writes:
> > On 2015-08-07 19:03, Alvise Rigo wrote:
> >> Introduce the new --enable-tcg-ldst-excl configure option to enable the
> >> LL/SC operations only for those backends that support them.
> >> 
> >> Suggested-by: Jani Kokkonen <address@hidden>
> >> Suggested-by: Claudio Fontana <address@hidden>
> >> Signed-off-by: Alvise Rigo <address@hidden>
> >> ---
> >>  configure | 21 +++++++++++++++++++++
> >>  1 file changed, 21 insertions(+)
> >
> > We have seen that for this kind of patch, it's better to add support in
> > all backends, otherwise it takes ages to get all the backends converted.
> > I think you should involve the backend maintainers. I can try to provide
> > the corresponding patches for mips and ia64.
> We discussed this on the last MTTCG call and agree. However we will need
> help from the other TCG maintainers for the backends. The changes should
> be fairly mechanical though.
> However in the spirit of keeping trees building in the meantime should
> we change this from a configure option to just a static option for each
> given backend as it is converted?

I am not even sure we need a static option. I guess providing we are
doing that early enough in the 2.5 cycle, we can just add the new ops
and start using them. Of course we should put the backends maintainers
in the loop so they can fix that quickly and don't get a surprise weeks

That said, please see my other email, I am not sure we actually need to
modify backends, I think we can implement these new "ops" through


Aurelien Jarno                          GPG: 4096R/1DDD8C9B
address@hidden                 http://www.aurel32.net

reply via email to

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