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: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-3.4 required=3.0 tests=AWL,BAYES_00,BODY_8BITS, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id A320E1F8C8 for ; Thu, 16 Sep 2021 14:49:45 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 90E30385742E for ; Thu, 16 Sep 2021 14:49:44 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 90E30385742E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1631803784; bh=jYKdI5AQx0UIdmFogKaBa5wIbcy1J8qgQFTO/dSJlvY=; h=To:Subject:In-Reply-To:References:Date:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=OTROEfW/eDaPro5pPxE1hC7fzHQLRpvMpfuhU1ulmTQSdi6xdQOlJC9wGteJVdq6x ljnA/3P/VyfUBbjs3u7wSoJxOopCW4bgx8aAyy8WaqmA3/wMW6Q4XIQOsWkjRf1yBR fqeSZ2Kd+lT+ui4x13HWwoZ4KKJBi78Swfg5vbYU= Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by sourceware.org (Postfix) with ESMTPS id 959963858413 for ; Thu, 16 Sep 2021 14:49:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 959963858413 To: Paul Eggert , Peter Zijlstra , andrealmeid@collabora.com, mingo@redhat.com, dvhart@infradead.org, rostedt@goodmis.org, bigeasy@linutronix.de Subject: Re: [PATCH 16/20] futex: Implement sys_futex_waitv() In-Reply-To: References: <20210915140710.596174479@infradead.org> <20210915141525.621568509@infradead.org> Date: Thu, 16 Sep 2021 16:49:21 +0200 Message-ID: <87tuika83y.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Thomas Gleixner via Libc-alpha Reply-To: Thomas Gleixner Cc: dave@stgolabs.net, libc-alpha@sourceware.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, mtk.manpages@gmail.com, kernel@collabora.com, krisman@collabora.com Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On Wed, Sep 15 2021 at 10:34, Paul Eggert wrote: > On 9/15/21 8:37 AM, Peter Zijlstra wrote: >> I utterly detest timespec.. it makes no sense what so ever. >>=20 >> Can't we just, for new syscalls, simply use a s64 nsec argument and call >> it a day? > > This would stop working in the year 2262. Not a good idea. Make it u64 and it stops in 2552, i.e. 584 years from now which is plenty. Lot's of the kernel internal timekeeping will stop working at that point, so that interface is the least of my worries. And TBH, my worries about the Y2552 problem are extremly close to zero. > Any improvements on struct timespec should be a strict superset, not a=20 > subset. For example, you could advocate a signed 128-bit argument=20 > counting in units of attoseconds (10=E2=81=BB=C2=B9=E2=81=B8 s), the high= est power-of-1000=20 > resolution that does not lose info when converting from struct > timespec. Which requires a 128bit division on every syscall for no value at all. Thanks, tglx