From: Jakub Jelinek <jakub@redhat.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Ulrich Drepper <drepper@redhat.com>,
linux-kernel@vger.kernel.org, mingo@redhat.com
Subject: Re: [PATCH] Add FUTEX_CMP_REQUEUE futex op
Date: Fri, 21 May 2004 03:43:58 -0400 [thread overview]
Message-ID: <20040521074358.GG30909@devserv.devel.redhat.com> (raw)
In-Reply-To: <20040520233639.126125ef.akpm@osdl.org>
On Thu, May 20, 2004 at 11:36:39PM -0700, Andrew Morton wrote:
> > > It'll work OK on x86 because of the stack layout but is the same true of
> > > all other supported architectures?
> >
> > We add parameters at the end. This does not influence how previous
> > values are passed. And especially for syscalls it makes no difference.
> >
>
> what we're effectively doing is:
>
> void foo(int a, int b, int c)
> {
> }
>
> and from another compilation unit:
>
> foo(a, b);
>
> and we're expecting the a's and b's to line up across all architectures and
> compiler options. I thought that on some architectures that only works out
> if the function has a vararg declaration.
The kernel syscall ABI is on many arches different from the compiler ABI.
Adding an argument this way certainly works on the architectures I'm
familiar with (i386, x86_64, ia64, ppc, ppc64, s390, s390x, sparc, sparc64,
alpha). I believe arm will work too, don't keep track of the rest of
arches.
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.
If some weirdo arch has problems with this, it can certainly deal with it in
its architecture wrapper.
Jakub
next prev parent reply other threads:[~2004-05-21 7:44 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 [this message]
2004-05-22 16:58 ` Arnd Bergmann
2004-05-24 7:34 ` Jakub Jelinek
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=20040521074358.GG30909@devserv.devel.redhat.com \
--to=jakub@redhat.com \
--cc=akpm@osdl.org \
--cc=drepper@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.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 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.