Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp5783328imu; Tue, 13 Nov 2018 11:39:54 -0800 (PST) X-Google-Smtp-Source: AJdET5eFTW/IjgSLvueIxuySIIcWBKoztA1/Cji7Wxe3rpSJowtyfFho1tQOGEzOM9QWTuMBr9W4 X-Received: by 2002:a17:902:748b:: with SMTP id h11mr6267362pll.325.1542137994689; Tue, 13 Nov 2018 11:39:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542137994; cv=none; d=google.com; s=arc-20160816; b=PqeFsknAT8GYh3lGIvJ+7Z7TWmiYO0Jux8oPyOYf32wrVP5AmwCDlaz6rvoREHXDQs G81qTGM15hjfeVLCw6iFhDhNdIbJwfDEdJVowSPcgyyJSQ/zo+Yl68Ci85ZK2nUBNl+D EEEjpIZD7PmJ3AoyLto35uKRzWUrUxAED5D03Fo2Vf0HvSuAgN4hPLllohb+9IS/PsXI fLs+5tPDS4jnzs8TSeTr8iOmC1QI55Y4NFZThDhgny8bD3y5atAAh25tLBJc9wXImGs+ vaH2AFXEzau6cw66EhrhiuAhBjX2gX5ub18gLp0gZUZOkb2HfmzEV5O/oHxhXPc+mI+k 6/PQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=NxcSrRuLdcFIx6RcSMfi4NZsr4vrn5veircVhx6ahms=; b=lCMMhWoX/BqohOMZuJDOjAqyydn/xCnQ/Pfh37/sNMKpbHueGNd/czJdXdiiOr5la7 5SAvE9rChoOFxUIkEdm8Ib95YAHAvd4oRt6UmFxSn6mrHCqIGYsU06ogjZ+bWr/Kc38T DaN5/ZVFY9WOy7FcREf9moMfg+A7ln+Mfnl7UMUtRbC92yq6sipe8ict7aAQch2dMeMO cd5rKmEDAaEnuNieeiae/ydsBuaZvNlsWJtiz4m5W9UCdm389UxsgipmkgUVyPv3mINi kUVRqtpSBSl8Xw2lNpGt7/295LVsaklDXFCMUJsYGVxyYQpn/txCBZaTCb5JvX9fvqna xnIQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x11-v6si21772154pln.425.2018.11.13.11.39.39; Tue, 13 Nov 2018 11:39:54 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727654AbeKNFik (ORCPT + 99 others); Wed, 14 Nov 2018 00:38:40 -0500 Received: from foss.arm.com ([217.140.101.70]:33946 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725748AbeKNFij (ORCPT ); Wed, 14 Nov 2018 00:38:39 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 44A05EBD; Tue, 13 Nov 2018 11:39:05 -0800 (PST) Received: from e103592.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 761E23F5BD; Tue, 13 Nov 2018 11:39:03 -0800 (PST) Date: Tue, 13 Nov 2018 19:39:01 +0000 From: Dave Martin To: Daniel Colascione Cc: Florian Weimer , "Michael Kerrisk (man-pages)" , linux-kernel , Joel Fernandes , Linux API , Willy Tarreau , Vlastimil Babka , Carlos O'Donell , "libc-alpha@sourceware.org" Subject: Re: Official Linux system wrapper library? Message-ID: <20181113193859.GJ3505@e103592.cambridge.arm.com> References: <877ehjx447.fsf@oldenburg.str.redhat.com> <875zx2vhpd.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 12, 2018 at 05:19:14AM -0800, Daniel Colascione wrote: [...] > We can learn something from how Windows does things. On that system, > what we think of as "libc" is actually two parts. (More, actually, but > I'm simplifying.) At the lowest level, you have the semi-documented > ntdll.dll, which contains raw system call wrappers and arcane > kernel-userland glue. On top of ntdll live the "real" libc > (msvcrt.dll, kernel32.dll, etc.) that provide conventional > application-level glue. The tight integration between ntdll.dll and > the kernel allows Windows to do very impressive things. (For example, > on x86_64, Windows has no 32-bit ABI as far as the kernel is > concerned! You can still run 32-bit programs though, and that works > via ntdll.dll essentially shimming every system call and switching the > processor between long and compatibility mode as needed.) Normally, > you'd use the higher-level capabilities, but if you need something in > ntdll (e.g., if you're Cygwin) nothing stops your calling into the > lower-level system facilities directly. ntdll is tightly bound to the > kernel; the higher-level libc, not so. > > We should adopt a similar approach. Shipping a lower-level > "liblinux.so" tightly bound to the kernel would not only let the > kernel bypass glibc's "editorial discretion" in exposing new > facilities to userspace, but would also allow for tighter user-kernel > integration that one can achieve with a simplistic syscall(2)-style > escape hatch. (For example, for a long time now, I've wanted to go > beyond POSIX and improve the system's signal handling API, and this > improvement requires userspace cooperation.) The vdso is probably too > small and simplistic to serve in this role; I'd want a real library. Can you expand on your reasoning here? Playing devil's advocate: If the library is just exposing the syscall interface, I don't see why it _couldn't_ fit into the vdso (or something vdso-like). If a separate library, I'd be concerned that it would accumulate value-add bloat over time, and the kernel ABI may start to creep since most software wouldn't invoke the kernel directly any more. Even if it's maintained in the kernel tree, its existence as an apparently standalone component may encourage forking, leading to a potential compatibility mess. The vdso approach would mean we can guarantee that the library is available and up to date at runtime, and may make it easier to keep what's in it down to sane essentials. Cheers ---Dave