From: "Ulrich Drepper" <drepper@gmail.com>
To: "Jakub Jelinek" <jakub@redhat.com>
Cc: "Ingo Molnar" <mingo@elte.hu>,
linux-kernel@vger.kernel.org,
"Ulrich Drepper" <drepper@redhat.com>,
"Paul Jackson" <pj@sgi.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Arjan van de Ven" <arjan@infradead.org>,
"Andrew Morton" <akpm@osdl.org>
Subject: Re: [patch 0/6] lightweight robust futexes: -V4
Date: Tue, 21 Feb 2006 08:26:05 -0800 [thread overview]
Message-ID: <a36005b50602210826i567effabsd4b43da9804db86d@mail.gmail.com> (raw)
In-Reply-To: <20060221092338.GV24295@devserv.devel.redhat.com>
On 2/21/06, Jakub Jelinek <jakub@redhat.com> wrote:
> TID address is registered through:
> pid_t set_tid_address (int *tidptr)
> syscall, so IMHO we should add a new syscall
> pid_t set_tid_robust_addresses (int *tidptr, struct robust_list_head *robustptr)
> which could register both tid and robust addresses.
The new syscall what certainly be used like this. In fact, the two
syscalls happen exactly one after the other in my sources. So I would
be in favor of making a change along these lines. But instead of
fixing the interface in this way it should be extendable. Pass a
structure and a flag value. The latter specifies which elements of
the structure are used. The structure could even grow over time.
> For thread creation, we can just add CLONE_CHILD_SETROBUST clone flag
> and if that flag is set, pass struct robust_list_head * as additional
> argument.
This is not necessary. Especially because we already reached the
limit of parameters to clone. A dedicated syscall to set up various
things like the TID pointer and the robust list is fine.
> The `len' argument (or really revision of the structure if really needed)
> can be encoded in the structure, as in:
> struct robust_list_head {
> struct robust_list list;
> short robust_list_head_len; /* or robust_list_head_version ? */
> short futex_offset;
> struct robust_list __user *list_op_pending;
> };
> or with long futex_offset, but using say upper 8 bits of the field as
> version or length.
I know you want to save SPARC but this kind of overloading I don't
really like. If you need special treatment of the futex value make
this explicit and arch-dependent.
next prev parent reply other threads:[~2006-02-21 16:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-21 8:46 Ingo Molnar
2006-02-21 9:23 ` Jakub Jelinek
2006-02-21 16:26 ` Ulrich Drepper [this message]
2006-02-21 16:37 ` Jakub Jelinek
2006-02-23 5:01 ` Eric W. Biederman
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=a36005b50602210826i567effabsd4b43da9804db86d@mail.gmail.com \
--to=drepper@gmail.com \
--cc=akpm@osdl.org \
--cc=arjan@infradead.org \
--cc=drepper@redhat.com \
--cc=jakub@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=pj@sgi.com \
--cc=tglx@linutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®