Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751511AbaFOTOn (ORCPT ); Sun, 15 Jun 2014 15:14:43 -0400 Received: from terminus.zytor.com ([198.137.202.10]:41509 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750979AbaFOTOj (ORCPT ); Sun, 15 Jun 2014 15:14:39 -0400 User-Agent: K-9 Mail for Android In-Reply-To: References: <21405.44257.742122.786960@gargle.gargle.HOWL> <20140615143500.GP179@brightrain.aerifal.cx> <539DD26B.3060709@zytor.com> <539DDE9C.3010903@zytor.com> <4ab91a07-c46c-485b-895d-b074d36624d6@email.android.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: [RFC 0/2] __vdso_findsym From: "H. Peter Anvin" Date: Sun, 15 Jun 2014 12:14:04 -0700 To: Andy Lutomirski CC: Andi Kleen , Rich Felker , Mikael Pettersson , Russ Cox , Linux API , Ian Taylor , "linux-kernel@vger.kernel.org" , X86 ML Message-ID: <90c597c5-f77d-491e-b0b8-dde2027155b5@email.android.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org If it doesn't, then you incur an additional indirection penalty. The strong __vdso symbol allows the libc wrapper to fall back to the vdso implementation, the weak symbol allows three to be no wrapper at all. This is good. The reason for changing ABI would be shifting types. This is very much how glibc manages transitions. On June 15, 2014 11:54:10 AM PDT, Andy Lutomirski wrote: >On Sun, Jun 15, 2014 at 11:39 AM, H. Peter Anvin wrote: >> Symbol versioning so we can rev the ABI and still provide backwards >compatibility. Weak symbols so the libc can override symbols if it >considers it appropriate. This is a good thing. > >Are we ever going to change, say, the __vdso_clock_gettime ABI without >renaming the function? If we want to preserve that ability, I can >keep support for versions, but it seems odd. > >I don't buy the weak symbol argument at all. We currently expose a >strong symbol __vdso_clock_gettime and a weak alias clock_gettime. I >agree that, if glibc treats us as a real DSO, then clock_gettime can't >be strong, but I don't see why it should exist at all (other than for >backwards compatibility). > >--Andy -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- 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/