From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-103150-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 25887 invoked by alias); 26 Jun 2019 16:28:28 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 25874 invoked by uid 89); 26 Jun 2019 16:28:28 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=fallen, H*f:sk:8736jwj, H*i:sk:8736jwj
X-HELO: mx1.suse.de
From: Andreas Schwab <schwab@suse.de>
To: Florian Weimer <fweimer@redhat.com>
Cc: Arnd Bergmann <arnd@arndb.de>,  Zack Weinberg <zackw@panix.com>,  Alistair Francis <alistair.francis@wdc.com>,  GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable
References: <cover.1561421042.git.alistair.francis@wdc.com>
	<2df9d3878359585ac1cc46243fb6664f7a50b3b3.1561421042.git.alistair.francis@wdc.com>
	<CAKCAbMhyUiEZcfg-BNL_sqUAFmtEWCEgoyUwMGOdB_jLbvKJ6Q@mail.gmail.com>
	<87ftnx6i0m.fsf@oldenburg2.str.redhat.com>
	<CAK8P3a39tr-qbG4X8SnM=3M6VfV+LzOvE6pVBqByN0YcPkf42w@mail.gmail.com>
	<877e9950hj.fsf@oldenburg2.str.redhat.com>
	<CAK8P3a0P1f=922peKELqanZqSY3MAdNiUK70UvZaxy75pS-2Qw@mail.gmail.com>
	<CAK8P3a2hj24voTemN54gBKay+cKU3vd_dr=KVacWjrO5foH3Bg@mail.gmail.com>
	<87a7e522wb.fsf@oldenburg2.str.redhat.com>
	<CAK8P3a3b32CNaXfR1w8cJuGS1H7qPTKLZc0BDxf-oW20i7aXvw@mail.gmail.com>
	<87r27hzrjd.fsf@oldenburg2.str.redhat.com>
	<CAK8P3a2HC_Ki0tf9B_A3Tm5w9zqrVLO8JG8u_ohc8aoSEY5okw@mail.gmail.com>
	<87ef3hzqjw.fsf@oldenburg2.str.redhat.com>
	<CAK8P3a2QW7WNuK0_zu44_fp3qWh7iL2V6Mae+zx+iLjUP7CitQ@mail.gmail.com>
	<8736jwjqkq.fsf@oldenburg2.str.redhat.com>
X-Yow: Yow!  It's some people inside the wall!  This is better than mopping!
Date: Wed, 26 Jun 2019 16:28:00 -0000
In-Reply-To: <8736jwjqkq.fsf@oldenburg2.str.redhat.com> (Florian Weimer's
	message of "Wed, 26 Jun 2019 17:48:05 +0200")
Message-ID: <mvm36jwux93.fsf@suse.de>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SW-Source: 2019-06/txt/msg00759.txt.bz2

On Jun 26 2019, Florian Weimer <fweimer@redhat.com> wrote:

> * Arnd Bergmann:
>
> [Exposing futex as __NR_futex for 64-bit-only-time_t]
>
>> Is there any long-term advantage for your approach that I'm
>> missing?
>
> Userspace that calls futex and does not care about timeouts would just
> work on RV32 without any porting.

Calling syscalls directly is always going to be hard to keep up-to-date,
has been fallen apart a lot already.

> But this would still break if people actually go ahead with the removal
> of the 32-bit system calls (something I think is quite impossible to do,
> but some people seem to disagree).

I'd expect that the current futex syscall will continue to work for all
its subfunctions without absolute timestamp.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."