From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754198Ab3BDAay (ORCPT ); Sun, 3 Feb 2013 19:30:54 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:37045 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753873Ab3BDAax (ORCPT ); Sun, 3 Feb 2013 19:30:53 -0500 Date: Mon, 4 Feb 2013 00:30:47 +0000 From: Al Viro To: Hans-Christian Egtvedt Cc: Matthias Brugger , Haavard Skinnemoen , Andrew Morton , "Paul E. McKenney" , David Howells , Dave Jones , Will Deacon , linux-kernel@vger.kernel.org Subject: Re: [PATCH] arch: avr32: add dummy syscalls Message-ID: <20130204003047.GW4503@ZenIV.linux.org.uk> References: <1359291015-4544-1-git-send-email-matthias.bgg@gmail.com> <20130127195714.GA11224@samfundet.no> <20130127203009.GG4503@ZenIV.linux.org.uk> <20130127203954.GA22063@samfundet.no> <20130204001055.GV4503@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130204001055.GV4503@ZenIV.linux.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 04, 2013 at 12:10:55AM +0000, Al Viro wrote: > On Sun, Jan 27, 2013 at 09:39:54PM +0100, Hans-Christian Egtvedt wrote: > > > If you are OK with going that way, I could probably put together patches doing > > > just that. Note that for rt_sigsuspend/rt_sigreturn/sigaltstack the wrappers > > > are not needed at all - they can just use current_pt_regs() in syscall body. > > > IOW, all of syscall-stubs.S could be killed. > > > > Nice, could you put together the preprocessor stuff in a patch? It would be > > great to not having to write a re-occuring stub for each syscall that has 6+ > > arguments. > > > > Thanks for looking at this. > > Apologies about the delay... One question: what's the AVR32 C ABI for > passing 64bit arguments? The tricky bugger is sys_sync_file_range(); > it takes (s32, s64, s64, u32) as arguments and if not any pair of > registers can be used to pass 64bit value, we have more serious trouble > there... BTW, it's worse: both fadivse64 and fadvise64_64 are wired, neither of them has a wrapper and arguments are (s32, s64, u32, s32) and (s32, s64, s64, s32) resp. The former is OK unless you have restrictions on register pairs that can be used for 64bit; the latter is past the 5-register limit no matter what, so the wrapper is really needed.