From: Gerd Hoffmann <kraxel@redhat.com>
To: Matthew Wilcox <matthew@wil.cx>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
Ulrich Drepper <drepper@redhat.com>
Subject: Re: [PATCH v2] Add preadv and pwritev system calls.
Date: Fri, 12 Dec 2008 16:48:36 +0100 [thread overview]
Message-ID: <494287D4.2070909@redhat.com> (raw)
In-Reply-To: <20081212152929.GM26095@parisc-linux.org>
Matthew Wilcox wrote:
>> +asmlinkage ssize_t sys_preadv(unsigned long fd, const struct iovec __user *vec,
>> + unsigned long vlen, loff_t pos)
>> +asmlinkage ssize_t sys_pwritev(unsigned long fd, const struct iovec __user *vec,
>> + unsigned long vlen, loff_t pos)
>
> Are these prototypes required? MIPS and PARISC will need wrappers to
> fix them if they are. These two architectures have an ABI which
> requires 64-bit arguments to be passed in aligned pairs of registers,
> but glibc doesn't know that (and given the existence of syscall(3),
> can't do much about it even if it knew), so some of the arguments end up
> in the wrong registers.
>
> Things will go much better if we can prototype these as:
>
> asmlinkage ssize_t sys_preadv(unsigned int fd,
> const struct iovec __user *vec,
> loff_t pos, unsigned long vlen);
> asmlinkage ssize_t sys_pwritev(unsigned int fd,
> const struct iovec __user *vec,
> loff_t pos, unsigned long vlen);
Hmm. It is the argument ordering used by NetBSD, thats why I used that
too. It certainly should be the application-visible ordering. We'll
have glibc between apps and kernel though, so I think we can reorder the
arguments at syscall level if that helps on these archs. Cc'ing Ulrich
Drepper for comments on that.
> By the way, why did you make 'fd' an unsigned long? The rest of the
> kernel uses unsigned int.
sys_{readv,writev} have unsigned long too, this is where I got it from.
Don't know what the reason for this is, it looks a bit odd indeed.
cheers,
Gerd
next prev parent reply other threads:[~2008-12-12 15:48 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-12 14:00 [PATCH v2] Add preadv and pwritev system calls Gerd Hoffmann
2008-12-12 15:29 ` Matthew Wilcox
2008-12-12 15:48 ` Gerd Hoffmann [this message]
2008-12-12 15:51 ` Matthew Wilcox
2008-12-12 16:02 ` Gerd Hoffmann
2008-12-12 17:03 ` Matthew Wilcox
2008-12-12 17:03 ` Matthew Wilcox
2008-12-12 18:21 ` Alan Cox
2008-12-12 19:02 ` Russell King
2008-12-12 18:29 ` Scott Lurndal
2008-12-12 19:07 ` Russell King
2008-12-12 19:56 ` Gerd Hoffmann
2008-12-12 19:56 ` Gerd Hoffmann
2008-12-12 20:12 ` Russell King
2008-12-12 20:12 ` Russell King
2008-12-12 20:39 ` Gerd Hoffmann
2008-12-12 20:39 ` Gerd Hoffmann
2008-12-14 18:19 ` Pavel Machek
2008-12-14 18:19 ` Pavel Machek
2008-12-15 16:37 ` Jennifer Pioch
2008-12-15 20:43 ` Gerd Hoffmann
2008-12-16 9:57 ` Arnd Bergmann
[not found] ` <200812161057.03025.arnd-r2nGTMty4D4@public.gmane.org>
2008-12-17 1:45 ` Dan Mick
2008-12-17 1:45 ` [osol-code] " Dan Mick
2008-12-12 19:47 ` Arnd Bergmann
2008-12-12 20:02 ` Gerd Hoffmann
2008-12-14 11:49 ` Heiko Carstens
2008-12-15 4:14 ` Paul Mackerras
2008-12-15 6:20 ` David Miller
2008-12-12 15:40 ` Ralf Baechle
2008-12-12 16:59 ` Russell King
2008-12-13 1:18 ` Michael Kerrisk
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=494287D4.2070909@redhat.com \
--to=kraxel@redhat.com \
--cc=drepper@redhat.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@wil.cx \
/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