Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3228451imu; Sat, 24 Nov 2018 00:35:18 -0800 (PST) X-Google-Smtp-Source: AFSGD/VV+Ni4BmJIrvS4pNs5ThBxap7pKSyHS8LCKtMNFhEvMVZoa8Vm/9iT8NaxgKj8VPl2KCTt X-Received: by 2002:a17:902:6ac3:: with SMTP id i3-v6mr19184495plt.153.1543048518035; Sat, 24 Nov 2018 00:35:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543048518; cv=none; d=google.com; s=arc-20160816; b=DMbFIB0hA3h0hvlU6x1Df5j9gj6nW3j4KdkceSA04lc9w50jRDnuWPPigduSNrXurw 7ApTvHippka3H3AgEve+z7u2JWBVqBiBl+/c8JIgsYzlaao4mSkf9tVz7LfpGGtVTuqx QM64IQGPXZlUuhRZMl8E3SdPaSEXP8cQ5cjoTgEQj/C8BKjLY8qZ8Nf98OxMb5w9trsc JV0jSXbv2Ze2YvtgltoNOZwzH3xuP767KzjSJaRQ0bx4vB2ROL+4MZfbQ/MfgMUifanK IaHVmY5Du0PjzYXzc3gFNvwFblSbsX9tvzj+VD4pbXv0aDkeUV5ePOEdll8KhMXdljij b0yQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id:date :references:subject:cc:to:from; bh=zRy6j0yrCC4y826TIqd/3EWLnrIhEI7Dza4j693MUok=; b=mwiP7QjXnUjMnT7w9dLOXsdfHQIYeVqLVUXxvRygE4MU0oLERJcU+448kPxw4y+ddf LV/obEpuhcKzwD7/M7ADI8TVTZjzRVhpKxBXfEsq8ME09CpXeMnqhMr3nQhl0Tor++ru Ck7lVrVqQcW3cbDz8s64j4pdedZYLtBr1UrQJclSG/LgATwg0oXa4XwvW/N6/dVEaTEs VMsGYj0w6ZGBQ1m83wRs5dkG+b8xJA98AURI/kfsBxcuEUWe4A5RRdsGu5A00kWy91Gs U97EwuY8gl+Wliegs0x1VicVCYcOfv37DuWv8NzLcTwaW/u/9B3hj6DggaPPuWe4fD3o +M9A== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f16si21117246pgg.173.2018.11.24.00.35.03; Sat, 24 Nov 2018 00:35:17 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2504575AbeKXASy (ORCPT + 99 others); Fri, 23 Nov 2018 19:18:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44374 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2410046AbeKXASx (ORCPT ); Fri, 23 Nov 2018 19:18:53 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C8D083091D52; Fri, 23 Nov 2018 13:34:39 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-117-155.ams2.redhat.com [10.36.117.155]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E6A6410018FB; Fri, 23 Nov 2018 13:34:34 +0000 (UTC) From: Florian Weimer To: Daniel Colascione Cc: "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? References: <877ehjx447.fsf@oldenburg.str.redhat.com> <875zx2vhpd.fsf@oldenburg.str.redhat.com> Date: Fri, 23 Nov 2018 14:34:26 +0100 Message-ID: <87efbbvrx9.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.42]); Fri, 23 Nov 2018 13:34:40 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Daniel Colascione: > On Mon, Nov 12, 2018 at 12:11 AM, Florian Weimer wrote: >> * Daniel Colascione: >> >>> If the kernel provides a system call, libc should provide a C wrapper >>> for it, even if in the opinion of the libc maintainers, that system >>> call is flawed. >> >> It's not that simple, I think. What about bdflush? socketcall? >> getxpid? osf_gettimeofday? set_robust_list? > > What about them? Mentioning that these system calls exist is not in > itself an argument. But socketcall does not exist on all architectures. Neither does getpid, it's called getxpid on some architectures. >> There are quite a few irregularities > > So? I think it would be a poor approach to expose application developers to these portability issues. We need to abstract over these differences at a certain layer, and applications are too late. >> and some editorial discretion appears to be unavoidable. > > That's an assertion, not an argument, and I strongly disagree. *Why* > do you think "editorial discretion" is unavoidable? We do not want application authors to write code which uses socketcall, however it is the right system call for the BSD sockets API if you need compatibility back to Linux 2.6.32 and before. If we application authors seitched to socketall, applications would not be portable (at the source level) to new architectures which do not have socketcall. We do not want to force application authors to call osf_gettimeofday instead of gettimeofday on Alpha. We do not want to encourage library authors to call set_robust_list because doing so would break robust mutex support in any libc. >> Even if we were to provide perfectly consistent system call wrappers >> under separate names, we'd still expose different calling conventions >> for things like off_t to applications, which would make using some of >> the system calls quite difficult and surprisingly non-portable. > > 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. > We should adopt a similar approach. Most kernel developers claim that a stable userspace ABI is desirable. With your proposal, we need to maintain three stable ABI layers instead of two, without actually adding any functionality. That doesn't seem to be a good way of using developer resources. Thanks, Florian