All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] Fix TLS support on x86
Date: Thu, 21 Jun 2007 02:01:21 -0400	[thread overview]
Message-ID: <20070621060120.GO4033@devserv.devel.redhat.com> (raw)
In-Reply-To: <1182403868.2782.16.camel@shinybook.infradead.org>

On Thu, Jun 21, 2007 at 01:31:07PM +0800, David Woodhouse wrote:
> On Wed, 2007-06-20 at 18:42 +0200, Alexander Graf wrote:
> > implements futexes (this is mostly done by David Woodhouse as well,
> > FUTEX_WAKE_OP done by me)
> 
> #ifdef BSWAP_NEEDED, only FUTEX_OP_CMP_EQ and FUTEX_OP_CMP_NE will work
> as expected. If we want to do the rest then we'll need to implement
> FUTEX_OP_CMP_LT_WRONGENDIAN &c in the kernel.
> 
> Or maybe, since we don't do set_robust_list (and would need wrong-endian
> support in the kernel for that too), we can assume that it's all
> in-process, and hence all _within_ qemu, and we could actually implement
> the futex stuff entirely within qemu with qemu's own locking?
> 
> For now I think the safer option is just to leave FUTEX_WAKE_OP
> unimplemented. Jakub, what do you think?

FUTEX_WAKE_OP is just an optimization and the only op glibc uses is
FUTEX_OP_CLEAR_WAKE_IF_GT_ONE, so something that would need kernel help.
But all glibcs so far if syscall (SYS_futex, ... FUTEX_WAKE_OP, ...)
fails just fall back to syscall (SYS_futex, ... FUTEX_WAKE, ...) +
unlock.

So I think it is safe to leave FUTEX_WAKE_OP not supported for BSWAP_NEEDED.

	Jakub

  reply	other threads:[~2007-06-21  6:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-08 14:17 [Qemu-devel] [PATCH] Fix TLS support on x86 Alexander Graf
2007-06-18 19:21 ` Thiemo Seufer
2007-06-20 16:42   ` Alexander Graf
2007-06-21  5:31     ` David Woodhouse
2007-06-21  6:01       ` Jakub Jelinek [this message]
2007-06-21  7:11       ` Alexander Graf
     [not found]     ` <20070621225550.GB25967@networkno.de>
     [not found]       ` <1801E7EE-FF0A-4A43-88ED-4503DEBBC831@suse.de>
     [not found]         ` <20070621231612.GC25967@networkno.de>
2007-07-02 10:01           ` Alexander Graf
2007-11-13 18:44             ` Stefan Weil
2007-11-13 18:46               ` Thayne Harbaugh
2007-11-13 22:13                 ` Fabrice Bellard
2007-11-14 20:02                   ` Stefan Weil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070621060120.GO4033@devserv.devel.redhat.com \
    --to=jakub@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.