Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751555AbaFOPrn (ORCPT ); Sun, 15 Jun 2014 11:47:43 -0400 Received: from mail-ve0-f176.google.com ([209.85.128.176]:35783 "EHLO mail-ve0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751246AbaFOPrk (ORCPT ); Sun, 15 Jun 2014 11:47:40 -0400 MIME-Version: 1.0 In-Reply-To: <20140615143500.GP179@brightrain.aerifal.cx> References: <21405.44257.742122.786960@gargle.gargle.HOWL> <20140615143500.GP179@brightrain.aerifal.cx> From: Andy Lutomirski Date: Sun, 15 Jun 2014 08:47:19 -0700 Message-ID: Subject: Re: [RFC 0/2] __vdso_findsym To: Rich Felker Cc: Mikael Pettersson , Russ Cox , Linux API , Ian Taylor , "linux-kernel@vger.kernel.org" , X86 ML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jun 15, 2014 at 7:35 AM, Rich Felker wrote: > On Sun, Jun 15, 2014 at 04:25:37PM +0200, Mikael Pettersson wrote: >> Andy Lutomirski writes: >> > The idea is to add AT_VDSO_FINDSYM pointing at __vdso_findsym. This >> > implements __vdso_findsym. >> > >> > This would make it easier for runtimes that don't otherwise implement >> > ELF loaders to use the vdso. >> > >> > Thoughts? >> >> I'm opposed to this based on the principle that the kernel should NOT >> be a dumping ground for random code that user-space can and should >> implement for itself. As long as the vdso is correctly formatted ELF, >> then parsing it is easy, and the kernel should not care at all if or >> how user-space accesses it. > > Arguably, it was a mistake for the kernel to expose a virtual ELF to > begin with, and it should just have exposed a "lookup function by > name" operation to begin with. Yes this can be done in userspace, but > I see it more as a matter of "fixing a broken API design". Is the __vdso_findsym(name, version) approach good? I don't know why the vdso uses symbol versions at all, nor do I know why it uses weak symbol aliases. The vdso's "clock_gettime" isn't a drop-in replacement for glibc's: it doesn't touch error, and it returns negative error codes. It might make more sense to promise that the vdso will never export to functions with the same name but different versions and to just get rid of the version field from __vdso_findsym. I tried implementing this; it's untested, but the text size is only 230 bytes :) It might also make sense to look up by number. Yes, it smells like Windows DLLs, but it also looks awfully like Linux syscalls, which do just fine using a call-by-number scheme. --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/