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=-3.9 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 9A8A51F461 for ; Wed, 26 Jun 2019 14:38:08 +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:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; q=dns; s=default; b=sUc9 aHhqq1teLk43GwkIukmvnrW8lZXoD9DVT3yW03LX7FX9ys9SRvFBiQ7GDjyXu1qc EVJa0ifAONiYe293dZtVAvsDpdoYa6f5wV2JfH6ndOziZqtFJ0Mhzmptv0b0//mH vGghTv4Xo494ytk0MLmDgwUfVpmTZXqPEoHYD/8= 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:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; s=default; bh=kvH520g6cA C+JiQoOPO3yAvsvns=; b=vdBRoUqFcZrkPiele9rl5L1ETP5GV4/iGejTwGbDxs ZsKcIuPXlxG9h+buz91McCxrGzayJt5uR5Pn8MUo/VTneOigu8Ne/+UTr1buEfYj 9ccafklPKrWnTBdECE8YJNXzMmS0VMM2JoubbSKdXJlZ+juFWpUTjMa1vka2MPvy 8= Received: (qmail 84446 invoked by alias); 26 Jun 2019 14:38:06 -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 84158 invoked by uid 89); 26 Jun 2019 14:38:05 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-qk1-f193.google.com MIME-Version: 1.0 References: <2df9d3878359585ac1cc46243fb6664f7a50b3b3.1561421042.git.alistair.francis@wdc.com> <87ftnx6i0m.fsf@oldenburg2.str.redhat.com> <877e9950hj.fsf@oldenburg2.str.redhat.com> <87a7e522wb.fsf@oldenburg2.str.redhat.com> <87r27hzrjd.fsf@oldenburg2.str.redhat.com> <87ef3hzqjw.fsf@oldenburg2.str.redhat.com> In-Reply-To: <87ef3hzqjw.fsf@oldenburg2.str.redhat.com> From: Arnd Bergmann Date: Wed, 26 Jun 2019 16:37:45 +0200 Message-ID: Subject: Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable To: Florian Weimer Cc: Zack Weinberg , Alistair Francis , GNU C Library Content-Type: text/plain; charset="UTF-8" On Tue, Jun 25, 2019 at 4:29 PM Florian Weimer wrote: > > I think this fails to take into account that the type differences have > clearly been abstracted away for struct timespec (you really need the > definition from an official header), and perhaps even for time_t. > > If there is only a 64-bit version of those types, the syscall name > difference does not add any value whatsoever. In glibc, I think we will > just add > > #define __NR_futex __NR_futex_time64 > > for these architectures (only internally, we won't define SYS_futex). > And any application that wants to call the futex system call directly > will do the same thing. Which leads to the question why the kernel > headers aren't doing it. I think it's a bad trade-off to do this hack for risc-v, and I don't really want to encourage it. Redefining __NR_futex for rv32 would clearly speed up the process of the initial merge because it avoids the dependency on the general ilp32-time64 support, but the cost would be to maintain rv32 as a special case forever. We already need three distinct variants of futex (and any other time64 syscall): a) 64-bit, timespec == __old_kernel_timespec == __kernel_timespec futex() -> syscall(__NR_futex) -> sys_futex b) 32-bit, timespec == __old_kernel_timespec; will stay around until ~2038 futex() -> syscall(__NR_futex) -> sys_futex c) 32-bit, timespec == __kernel_timespec, being added now futex() -> __futex_time64() -> syscall(__NR_futex_time64) -> sys_futex_time64 With __futex_time64() being an internal function like int __futex_time64(...) { int err = -ENOSYS; #ifdef __NR_futex_time64 err = syscall(__NR_futex_time64, ...); #endif #ifdef __NR_futex if (err = -ENOSYS) { /* pre-5.1 kernel */ struct __kernel_old_timespec ts32 = ts64_to_ts32(ts); err = syscall(__NR_futex_time64, ... &ts32 ...); } #endif return ret; } What I expected would happen here was to use the same as case c) for rv32, while your approach would be closer to a), with no intermediate function: d) rv32, timespec == __kernel_timespec futex() -> syscall(__NR_futex_time64) -> sys_futex_time64 This way you have to multiplex between time32 and time64 in two places: existing architectures by calling __futex_time64() instead of futex() (through whatever method you normally use in glibc to choose between different ABI variants at link time), while rv32 would use the old symbol but redefine the kernel macros to do the same thing. Is there any long-term advantage for your approach that I'm missing? Arnd