From: Arnd Bergmann <arnd@arndb.de>
To: "H. Peter Anvin" <hpa@zytor.com>, Paul Mackerras <paulus@samba.org>
Subject: Re: [klibc] Re: long long on 32-bit machines
Date: Sat, 31 Jan 2004 13:23:40 +0100
User-Agent: KMail/1.5.4
Cc: klibc list <klibc@zytor.com>, linux-kernel <linux-kernel@vger.kernel.org>
References: <4017F991.2090604@zytor.com> <16408.59474.427408.682002@cargo.ozlabs.ibm.com> <401B464C.50004@zytor.com>
In-Reply-To: <401B464C.50004@zytor.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200401311323.40399.arnd@arndb.de>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 967
Lines: 26

On Saturday 31 January 2004 07:08, H. Peter Anvin wrote:
> Does system calls follow the same convention?

I have just looked up in glibc what architectures need this kind
of handling and found that there is no easy rule. The good news
is that none of (hppa m68k s390 sparc x86_64 alpha cris i386 sparc64 
arm ia64) are doing this. 

AFAICS, the padding is done for exactly these system calls:

ppc: truncate64, ftruncate64, pread64, pwrite64
mips: truncate64, ftruncate64, pread64, pwrite64
sh: pread64, pwrite64

fadvise64_64 is another story: 
mips does no padding, ppc32 reorders the arguments (int fd, int advise,
off64_t offset, off64_t len) and s390 passes a struct, for the
reason Uli already explained.

	Arnd <><

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/