From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: [PATCH v2] Add preadv and pwritev system calls. Date: Fri, 12 Dec 2008 16:48:36 +0100 Message-ID: <494287D4.2070909@redhat.com> References: <1229090440-32120-1-git-send-email-kraxel@redhat.com> <20081212152929.GM26095@parisc-linux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.redhat.com ([66.187.237.31]:56025 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757165AbYLLPsx (ORCPT ); Fri, 12 Dec 2008 10:48:53 -0500 In-Reply-To: <20081212152929.GM26095@parisc-linux.org> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Matthew Wilcox Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Ulrich Drepper 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