From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 506AA1F461 for ; Mon, 8 Jul 2019 12:57:47 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type; q=dns; s=default; b=SKpf3 PBtaIICliF79/ILY1OSRHBCRtHSJJXn0vu2edlS6upZO1Dq/O5D4cGvJjkvhZe4B jVaxYWaidp9SztloOvhJsSBRcDH5b+YodrK+aNz+DxmGE4S/anfjIwR22pVKuP2q 2oVVFRye9X27xKbGp6CPPZs7S5yOgGqprUmC/c= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type; s=default; bh=gfap0QzA6CK ENqvwp7Vbe0RyI9U=; b=lmVUr28C/XEYsOdRBSzoiQ7jJR77BqQfUJ7eIm46g8A u1CBTab6nkdiaX0IimwuPFdMfs77ctQeInxAIXy7FrDNeb7Tumh0Mue/WnuNhkBr FgjxwBvmeWTA3zvT1W1Vc8N2/Dm9lr9VNnVosMhFE7scwIk0AIqssIzFkBpJiY/s = Received: (qmail 31401 invoked by alias); 8 Jul 2019 12:57:45 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 31387 invoked by uid 89); 8 Jul 2019 12:57:45 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mx1.redhat.com From: Florian Weimer To: Maciej Rozycki Cc: "libc-alpha\@sourceware.org" Subject: Re: glibc at the Toolchains microconference at LPC 2019 References: <87o92kibdz.fsf@oldenburg2.str.redhat.com> Date: Mon, 08 Jul 2019 14:57:32 +0200 In-Reply-To: (Maciej Rozycki's message of "Thu, 27 Jun 2019 17:45:41 +0000") Message-ID: <87y318r8eb.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain * Maciej Rozycki: >> glibc system call wrappers are on the agenda: >> >> >> >> Will anyone from the glibc community attend and can set the right >> expectations? > > I plan to be there and I can carry the message. Great, then we need to decide what it would be. Maybe the following is a reasonable starting point? The glibc project decided a while back that it wants to add wrappers for system calls which are useful for general application usage. However, that doesn't mean that all those missing system calls are added immediately. System call wrappers still need documentation in the manual, which is can be difficult in areas where there is no consensus how to describe the desired semantics (e.g., in the area of concurrency). (Copyright assignment to the FSF is needed for both the code and the manual update, but can usually performed electronically these days, and is reasonably straightforward.) On top of that, the glibc project is seriously constrained by available reviewer bandwidth. Some more specific notes: Emulation of the system call is not required. It has been historically very problematic. The only thing that has not come back to bite us is checking if a new flag argument is zero and call the old, equivalent system call instead in this case. Wrapper names should be architecture-independent if at all possible. Sharing system call names as much as possible between architectures in the UAPI headers helps with that. Mutiplexing system calls are difficult to wrap, particularly if the types and number of arguments vary. Previous attempts to use varargs for this have lead to bugs. For example, open/openat would not pass down the mode flag for O_TMPFILE initially, or cannot be called with a non-variadic prototype/function pointer on some architectures. We wouldn't want to wrap socketcall (even if it had not been superseded), and may wrap futex as separate functions. We strongly prefer if a system call that is not inherently architecture-specific (e.g., some new VFS functionality) is enabled for all architectures in the same kernel release. When it comes to exposes the system call, we prefer to use size_t for buffer sizes (even if the kernel uses int or unsigned int), purely for documentation purposes. Flag arguments should not be long int because it is unclear whether in the future, more than 32 flags will be added on 64-bit architectures. Except for pthread_* functions, error reporting is based on errno and special return values. Passing file offsets through off64_t * arguments is fine with us. Otherwise, off64_t parameter passing tends to vary too much. If constants and types related to a particular system call are defined in a separate header which does not contain much else, we can incldue that from the glibc headers if available. As a result, new kernel flags will become available to application developers immediately once they install newer kernel headers. (This may not work for multiplexing system calls, of course, even if we wrap the multiplexer.) Any other comments? Thanks, Florian