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 AA27B1F461 for ; Sat, 29 Jun 2019 06:27:43 +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=qDZVz dAEmRvUU6nkP/mnE9HzQpghO7zLA0XDAo82pd2Pfn6iiof+W8VoFwUM9HSQqbhJm EgL/Vk0spqnFg7/MqWn6rl3xlbfr1oU4kPz0E69OMEvkM3db9uXRpqrqwuzhfJlt 1k3rartSb4Fb0G2HhS+A+kKbpzbhsxWQgfl89s= 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=kvqgqbQNMEJ PLzFrDQIRM4oYle8=; b=h5pbcXuSn5eqmGXu+dsPLrD0+L7iq3y4PrQtUekYHsQ 6df1LzTnwC8sFhIH4cTZDpjhLj2TNCx379SUKDMdLm7MHe9nmQWzRPmV8ytGk8eR MiyC4K+ZwEK5IUuaFwmutUQ4b9P1ysfBnDjcFOeV/mhl1ZCeFYFAZ08sXZ6m52cA = Received: (qmail 45268 invoked by alias); 29 Jun 2019 06:27:41 -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 45260 invoked by uid 89); 29 Jun 2019 06:27:40 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mx1.redhat.com From: Florian Weimer To: Zack Weinberg Cc: "Dmitry V. Levin" , "Carlos O'Donell" , GNU C Library Subject: Re: wrappers for multiplexed syscalls (was Re: glibc at the Toolchains microconference at LPC 2019) References: <87o92kibdz.fsf@oldenburg2.str.redhat.com> <20190626163908.GA13251@altlinux.org> <530DF2A2-2D76-43F6-81D0-405EFE097A57@brauner.io> <5f740811-e7d7-6ece-4156-89651666e416@redhat.com> <20190627093928.GA25423@altlinux.org> <20190627205259.GA818@altlinux.org> <87ef3eu3iy.fsf@mid.deneb.enyo.de> <20190628212040.GB18013@altlinux.org> <87blyhjsvs.fsf@oldenburg2.str.redhat.com> Date: Sat, 29 Jun 2019 08:27:32 +0200 In-Reply-To: (Zack Weinberg's message of "Fri, 28 Jun 2019 21:52:24 -0400") Message-ID: <87o92gj48b.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 * Zack Weinberg: > On Fri, Jun 28, 2019 at 5:35 PM Florian Weimer wrote: >> >> * Dmitry V. Levin: >> >> > What if we start adding separate functions for new interfaces of already >> > existing multiplexed system call wrappers? >> > >> > For example, ptrace is going to gain a new command (PTRACE_GET_SYSCALL_INFO) >> > in Linux 5.3. My initial plan was just to update sys/ptrace.h with a new >> > constant and bits/ptrace-shared.h with a new structure, but I could add >> > a new function as well: >> > >> > extern int ptrace_get_syscall_info (__pid_t __pid, >> > struct __ptrace_syscall_info *__infop) >> > __THROW; >> >> I think this makes a lot of sense. We should also do this for existing >> constants (and for fcntl, too). Perhaps after we have added more of the >> wrappers that are *completely* missing, though. > > Yeah, I like this idea as well. I think we should keep exposing the > multiplexed interfaces, though, just because sometimes they do add new > opcodes (e.g. the OFD locks). Maybe. But not as varargs functions, so that there's no ambiguity how many arguments need to be extracted and passed to the system call (which caused interoperability problems with open/openat). Thanks, Florian