Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751570AbaB0UMP (ORCPT ); Thu, 27 Feb 2014 15:12:15 -0500 Received: from mail-vc0-f177.google.com ([209.85.220.177]:45557 "EHLO mail-vc0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750999AbaB0UMN (ORCPT ); Thu, 27 Feb 2014 15:12:13 -0500 MIME-Version: 1.0 In-Reply-To: <530ECBB1.40806@zytor.com> References: <20140227033920.GI12219@tassilo.jf.intel.com> <530EC7D1.3000706@zytor.com> <530ECBB1.40806@zytor.com> From: Andy Lutomirski Date: Thu, 27 Feb 2014 12:11:52 -0800 Message-ID: Subject: Re: [PATCH 1/2] x86: Mark __vdso entries as asmlinkage To: "H. Peter Anvin" Cc: Andi Kleen , Stefani Seibold , X86 ML , Greg KH , "linux-kernel@vger.kernel.org" , Thomas Gleixner , Ingo Molnar , Andrea Arcangeli , John Stultz , Pavel Emelyanov , Cyrill Gorcunov , andriy.shevchenko@linux.intel.com, Martin.Runge@rohde-schwarz.com, Andreas.Brief@rohde-schwarz.com Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 26, 2014 at 9:22 PM, H. Peter Anvin wrote: > On 02/26/2014 09:19 PM, Andy Lutomirski wrote: >>> >>> The normal ABI almost certainly makes more sense; as such -mregparm=3 is >>> probably not what we want, and I suspect it makes more sense to just >>> drop that from the CFLAGS line? >> >> Hmm. What happens on a native 32-bit build? IIRC the whole kernel is >> build with regparm(3). >> > > Well, the vdso is still built separately, so we can use different CFLAGS > if we want to. > >> If we want to save a cycle or two, then regparm(3) is probably faster. >> But I think that these functions should either be asmlinkage or (on >> 32 bit builds) explicitly regparm(3) to avoid confusion. > > I suggest using the standard ABI, but I suggest doing it via CFLAGS. Hmm. This sort of goes against existing x86_32 practice where, AFAICT, things that need a particular calling convention specify asmlinkage and everything else uses regparm(3) if config/kbuild thinks it's appropriate. But I'm happy to resubmit the patch if you prefer the CFLAGS approach for the 32-bit vdso. I don't think anything will break, since I don't think that the 32-bit vdso has any other exported C code. > > It isn't any faster if the C library has to provide a wrapper just to > marshal parameters. Probably true, given that the glibc wrapper could, in principle, use an optimized tail call. Also, I see no reason why vdso functions, alone of all userspace code, should be special. --Andy -- 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/