public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Andrew Morton <akpm@osdl.org>,
	Ulrich Drepper <drepper@redhat.com>,
	linux-kernel@vger.kernel.org, mingo@redhat.com,
	Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [PATCH] Add FUTEX_CMP_REQUEUE futex op
Date: Mon, 24 May 2004 03:34:07 -0400	[thread overview]
Message-ID: <20040524073407.GC4736@devserv.devel.redhat.com> (raw)
In-Reply-To: <200405221858.44752.arnd@arndb.de>

On Sat, May 22, 2004 at 06:58:41PM +0200, Arnd Bergmann wrote:
> On Friday 21 May 2004 09:43, Jakub Jelinek wrote:
> > Well, for s390/s390x there is a problem that it doesn't allow (yet) 6
> > argument syscalls at all, so one possibility for s390* is adding a wrapper around
> > sys_futex which will take the 5th and 6th arguments for FUTEX_CMP_REQUEUE
> > from a structure pointed to by 5th argument and pass that to sys_futex.
> 
> I would really prefer not re-inventing brain-damage like ipc_kludge. I
> have tried to do a special s390_futex_cmp_requeue() syscall, which is
> still somewhat ugly. At least it has the advantage that it does not break
> the de-facto calling conventions for s390 syscalls that either pass
> up to five arguments in r2 to r6 or everything in an array pointed to
> by r2.
> 
> Martin and Jakub, does the patch below look ok to you or should we do
> it in yet another way?

My personal preference is:
1) change s390* entry*.S so that all syscalls can use up to 6 arguments,
   otherwise we'll have the same problem every now and then
   (last syscall before this one was fadvise64_64 if I remember well)
2) allow sys_futex to have 6 arguments (the 6th on the stack, get_user'ed
   from an s390 wrapper)
3) special structure passed in 5th argument for FUTEX_CMP_REQUEUE
4) your solution
   (you have a special wrapper around futex anyway, so why not to handle
   it there already and create completely new syscall).

That said, NPTL can deal with any of these variants and the decision
is up to Martin I think (assuming the base patch gets accepted, that is).
http://listman.redhat.com/archives/phil-list/2004-May/msg00031.html
is the latest version of the userland part of FUTEX_CMP_REQUEUE changes
(against CVS glibc) and there futex_requeue () macro is defined
in arch specific headers, so nptl/sysdeps/unix/sysv/linux/s390/lowlevellock.h
can do there its own black magic.

	Jakub

  reply	other threads:[~2004-05-24  7:35 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-20  9:38 [PATCH] Add FUTEX_CMP_REQUEUE futex op Jakub Jelinek
2004-05-20 22:52 ` Andrew Morton
2004-05-21  6:06   ` Ulrich Drepper
2004-05-21  6:36     ` Andrew Morton
2004-05-21  7:15       ` Ulrich Drepper
2004-05-21  7:43       ` Jakub Jelinek
2004-05-22 16:58         ` Arnd Bergmann
2004-05-24  7:34           ` Jakub Jelinek [this message]
2004-05-24  8:12             ` Andrew Morton
2004-05-24  8:19               ` Jakub Jelinek
2004-05-28 13:09                 ` DOCUMENTATION " bert hubert
2004-05-28 14:02                   ` Jakub Jelinek
2004-05-28 15:39                     ` bert hubert
2004-05-24  8:27               ` bert hubert
2004-05-24 17:34             ` Arnd Bergmann
2004-05-21  7:05   ` Ingo Molnar
2004-05-21 23:05 ` Andrew Morton
2004-05-22 10:10   ` Ingo Oeser
2004-05-23 17:33   ` Jakub Jelinek
2004-05-29  3:13 ` Rusty Russell
  -- strict thread matches above, loose matches on Subject: below --
2004-06-07 16:03 Martin Schwidefsky
     [not found] <mailman.1086629984.12568.linux-kernel2news@redhat.com>
2004-06-09 20:04 ` Pete Zaitcev
2004-06-09 22:08   ` Arnd Bergmann
2004-06-11  8:35   ` Martin Schwidefsky

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=20040524073407.GC4736@devserv.devel.redhat.com \
    --to=jakub@redhat.com \
    --cc=akpm@osdl.org \
    --cc=arnd@arndb.de \
    --cc=drepper@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=schwidefsky@de.ibm.com \
    /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