From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9F544C43441 for ; Tue, 13 Nov 2018 19:39:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6A6A120818 for ; Tue, 13 Nov 2018 19:39:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6A6A120818 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727975AbeKNFik (ORCPT ); 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