From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: + preadv-pwritev-add-preadv-and-pwritev-system-calls.patch added to -mm tree Date: Tue, 3 Feb 2009 12:19:54 -0800 (PST) Message-ID: References: <200902022135.n12LZa1a010673@imap1.linux-foundation.org> <49876A91.4000705@zytor.com> <49881904.30705@redhat.com> <498879B3.8030002@zytor.com> <20090203171559.GA20898@flint.arm.linux.org.uk> <49887EF4.1090300@zytor.com> <20090203174257.GC20898@flint.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <20090203174257.GC20898@flint.arm.linux.org.uk> Sender: linux-arch-owner@vger.kernel.org To: "H. Peter Anvin" , Gerd Hoffmann , akpm@linux-foundation.org, mm-commits@vger.kernel.org, arnd@arndb.de, linux-api@vger.kernel.org, linux-arch@vger List-Id: linux-api@vger.kernel.org > > I'm thinking there of the silly fadvise64_64 syscall, where ARM was forced > into having a different argument ordering from everything else through > zero discussion. > > So, what would your scripts do with the fadvise64_64 syscall on an > architecture requiring natural alignment of the 64-bit args in 32-bit > regs? > It depends on the exact rules: in most cases, it doesn't have to do anything, because the calling convention on the user side and on the kernel side simply cancel out. This was lesson #1 while implementing klibc (which does all system calls that aren't totally ad hoc via autogenerated stubs.) If, however, it is needed, the scripts I have can handle arbitrary weirdness, including stuff like needing manual splitting and even passing 64-bit arguments by reference. The important bit here is consistent rules, but ad hoc rules that are per system call (as opposed to a set of *per platform* rules that are adhered to) is just a disaster -- and one from which we can never recover with any kind of automation. Inconsistencies here hurt everything that involves the system call interface: all libcs, the kernel itself, strace etc. -hpa