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=-10.1 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_PASS,USER_IN_DEF_DKIM_WL 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 8D1D7C43441 for ; Mon, 12 Nov 2018 19:26:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 48C2222506 for ; Mon, 12 Nov 2018 19:26:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="po6TpHpe" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 48C2222506 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.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 S1726160AbeKMFVb (ORCPT ); Tue, 13 Nov 2018 00:21:31 -0500 Received: from mail-vk1-f179.google.com ([209.85.221.179]:42208 "EHLO mail-vk1-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725790AbeKMFVb (ORCPT ); Tue, 13 Nov 2018 00:21:31 -0500 Received: by mail-vk1-f179.google.com with SMTP id y14so2217515vky.9 for ; Mon, 12 Nov 2018 11:26:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nkJNME0hKQObx3H83kU8pvC0TbOAY5SjRYkRmAXv2qc=; b=po6TpHpeZUQpnpzLCiBNbLTrkZMYvWSD1szQVk6HqWjFyZMkzXq7suHl5neZlVSva1 n/6drcdDZqfbfOsQmEzGR6TtO4MA5FToBUhNz6JcWY+9zb4S95D04m4y+bY6zv333k+I Sqyf5mxyCH6ReYT6OqAWIN6aRluecXWhkPFlIvvNIWZz6PiEiDQ1h2J5rRwYxD3cZ5S5 QM7L8WFfbaoGiJnEAqPOn0LfJe9HHLyjE36DCeoNf/KcBgszY2aCvvx3voiwnpLLViPo y5QzDjk5moi8J5NWvjhp8QpTaHKM8niq7ubj/pL9KwKGJVB7TXbtKZ/Hrvse/7hJuxLc X/SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nkJNME0hKQObx3H83kU8pvC0TbOAY5SjRYkRmAXv2qc=; b=bs0Mx1fvKkMKWiTWQnaAdatht/TRJgTefMJChJ6cyoM8XXmv8ySswE56k5H8TWP4zS hWfalj2BPzjrb5WZ2dUJS7q7MBZ9ngxfw73ifmY9+sLPYJl9lH4L12YR8ub+KCPEVgvs 7/XbFbwjHlGYen9i1r6lnt9LsQid4Wd939L+AxlRmcPVHOsluyU5ZF7khsD3GZft54Zv aEWBAQCqwlCB3h+Et5R3ptwsFtsf/uiAvRxD8F0xmxRCVVYPM93lBzSIm1omEx5FIY2G kKX6gcxopvUqdMVZytx626lwyOvD2kpHy7qU8L5EZCBda2MO5ovxgEQWgd8dJtQ7J1FC lyww== X-Gm-Message-State: AGRZ1gJ3gYRPNY3+nsnz8cZpw4UPqWMP1lqusLp36KuKNzTzWfnOybki PcdQd09fZ+IpZg9NTlbcKn4D65W8ecmWM+2HrFPBgw== X-Google-Smtp-Source: AJdET5ftrdpA6CnDWCUe07KXvy3gxGwqGYiVbYmaCFKLJbVZOzG0g1Cnt8gAmNJN6c0a4vO3cLph75gKtc/SXlykxMI= X-Received: by 2002:a1f:f203:: with SMTP id q3mr968323vkh.54.1542050813423; Mon, 12 Nov 2018 11:26:53 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a67:f48d:0:0:0:0:0 with HTTP; Mon, 12 Nov 2018 11:26:51 -0800 (PST) In-Reply-To: <87lg5ym7qi.fsf@oldenburg.str.redhat.com> References: <877ehjx447.fsf@oldenburg.str.redhat.com> <875zx2vhpd.fsf@oldenburg.str.redhat.com> <87lg5ym7qi.fsf@oldenburg.str.redhat.com> From: Daniel Colascione Date: Mon, 12 Nov 2018 11:26:51 -0800 Message-ID: Subject: Re: Official Linux system wrapper library? To: Florian Weimer Cc: Zack Weinberg , "Michael Kerrisk (man-pages)" , Linux Kernel Mailing List , Joel Fernandes , Linux API , Willy Tarreau , Vlastimil Babka , "Carlos O'Donell" , GNU C Library Content-Type: text/plain; charset="UTF-8" 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 11:11 AM, Florian Weimer wrote: > * Daniel Colascione: > >> What about off_t differences? Again, it doesn't matter. From the >> *kernel's* point of view, there's one width of offset parameter per >> system call per architecture. The library I'm proposing would expose >> this parameter literally. > > Does this mean the application author needs to know when to split an > off_t argument into two, and when to pass it as a single argument, and > when to insert dummy arguments for alignment, depending on the > architecture? No, I wouldn't make callers go to that trouble. I don't see any barrier to common-sense local data transformations. These transformations don't have external dependencies, after all. I want a thin interface to the kernel, but not so thin as to be a direct mapping onto register locations. I don't see value in that level of correspondence. >>> And that means you wouldn't get as much >>> decoupling from the C and POSIX standards -- both of which specify at >>> least part of those semantics -- as you want, and we would still be >>> having these arguments. For example, it would be every bit as >>> troublesome for liblinuxabi.so.1 to export set_robust_list as it would >>> be for libc.so.6 to do that. >> >> Why? Such an exported function would cause no trouble until called, >> and there are legitimate reasons for calling such a function. Not >> everyone, as mentioned, wants to write a program that relies on libc. > > For that use case, a machine-readable system call ABI specification is > the only reasonable approach: > The challenge here is to come up with a > uniform description of the system call interface for all architectures, This is another example in which we should remember the old aphorism that the perfect is the enemy of the good. There's no reason that the kernel couldn't simply provide a library with conventional functions exported in the conventional way doing the conventional things that functions do, one that would free users from relying on direct use of syscall(2). If this library were to interact with errno and cancelation properly, so much the better. There's no reason to avoid this work in favor of some theoretically-elegant abstract-function-description metadata-based approach that will likely never materialize. (Alternatively: just regard C as the uniform description language.) >> This stance in the paragraph I've quoted is another example of glibc's >> misplaced idealism. As I've elaborated elsewhere, people use signals >> for many purposes today. The current signals API is extremely >> difficult to use correctly in a process in which multiple unrelated >> components want to take advantage of signal-handling functionality. >> Users deserve a cleaner, modern, and safe API. It's not productive >> withhold improvements to the signal API and gate them on unrelated >> features like process handles merely because, in the personal >> judgement of the glibc maintainers, developers should use signals for >> fewer things. > > The two aren't unrelated. If you take asynchronous signals out of the > picture, the design becomes simpler and easier to use. The two features *are* unrelated. The design I've proposed works equally well for synchronous and asynchronous signals, and limiting it to synchronous signals doesn't simplify it. Even if it were the case that the design were simpler and easier to use when limited to synchronous signals --- which it isn't, unless you want to go in the SEH direction, which is more, not less complicated --- that wouldn't be a reason to block the work until some form of process handle landed. The objections I've seen have all essentially amounted to "we don't think people should use signals".