From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:51920)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1UtlGh-0004PL-5o
	for qemu-devel@nongnu.org; Mon, 01 Jul 2013 17:04:16 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1UtlGg-0001Tx-52
	for qemu-devel@nongnu.org; Mon, 01 Jul 2013 17:04:15 -0400
Received: from mx1.redhat.com ([209.132.183.28]:53905)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1Utl5O-0006fk-EE
	for qemu-devel@nongnu.org; Mon, 01 Jul 2013 16:52:34 -0400
Message-ID: <51D1EC0D.50304@redhat.com>
Date: Mon, 01 Jul 2013 22:52:29 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <1372444009-11544-1-git-send-email-pbonzini@redhat.com>
	<1372444009-11544-6-git-send-email-pbonzini@redhat.com>
	<CAFEAcA8VnPTwFHhCQ68uVanjQt0jeH+4VNvNbDqe1idJQLnk4A@mail.gmail.com>
	<51D15DDC.3030705@redhat.com>
	<CAFEAcA87E3G7EaFQ0U-2CkxqTOshhh4-jAi6XrGGXyvg0mFq1g@mail.gmail.com>
	<51D1AC75.3000000@redhat.com>
	<CAFEAcA8GDxne8qvTjYWt00zNJKY2c6eeSGcoTow7H8M6BgE-eg@mail.gmail.com>
In-Reply-To: <CAFEAcA8GDxne8qvTjYWt00zNJKY2c6eeSGcoTow7H8M6BgE-eg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 05/30] exec: do not use qemu/tls.h
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-devel@nongnu.org

Il 01/07/2013 18:26, Peter Maydell ha scritto:
> > I think we should strive for one of these two:
> >
> > (1) all targets are TLS;
> >
> > (2) all targets are non-TLS if this is possible.
> >
> > Either maximizes the homogeneity across platforms.
> 
> Since the two largest cases are both "cpu_single_env must be TLS"
> (ie (a) system emulation built with KVM support and (b) linux-user),
> the set of targets which can be non-TLS is really really small,
> and I think (1) makes much more sense.

Not many linux-user targets support threads (including not i386).

> (I'm assuming you don't want to try to support cpu_single_env
> being both per-thread and not-per-thread in a single binary
> depending on whether the user passes -enable-kvm or not.)

No, of course not.