From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by sourceware.org (Postfix) with ESMTPS id 10A4A3858D1E for ; Mon, 15 Jan 2024 20:29:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 10A4A3858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arndb.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arndb.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 10A4A3858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=64.147.123.19 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705350597; cv=none; b=DFZWIrvJqotOPjcbuRxMAcy+1iTSV1/v7F/NZ1IDH/a66mn43BU3l7uE+0iOvxBjijBQ7HaYu/okiv4lUdguhJAJV4rVn8uI/BUF34MBxF8d7/dVI2VoQsRT96yrD9oZydzyrAeTYm6gqHQwJ2MnFHmmsPIFCGhnHEmoBJbHxBQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705350597; c=relaxed/simple; bh=R5j/NN1QKPpeWOvwKfQRXu9DDSWqvk/sje8fKOYhZLE=; h=DKIM-Signature:DKIM-Signature:MIME-Version:Message-Id:Date:From: To:Subject; b=UD8Vm1ScISVD4kb1/7JPuFOaddy23EnKdypk5XyvW/KU2PZq20XajLJRG/yiQDRcT8sqor0C5GoprX9FFx5kzw83diDhAtAbKWe9n36TUCPST1PeVF1gpwmwes7hJK6XJiuKvnT+8gPzPirn+MsEeJgXmQCkds5jPsrYZD7UWRQ= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 111373200A6A; Mon, 15 Jan 2024 15:29:49 -0500 (EST) Received: from imap51 ([10.202.2.101]) by compute5.internal (MEProxy); Mon, 15 Jan 2024 15:29:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1705350589; x=1705436989; bh=mfvxTqywSw QPpZIAHcZQJci945RwdVqo25EbQJY/r/U=; b=QVAfBRM8kxYT29MX6huI1oKLMp Y1eGxERVQoUjpcjbAHcpH3J51gaqjbZmAMJTd984p+TxBwNeccr1ICncclvCYkeV eB/rsuOn04qMI8vIyXV+u0Tc8lgMFADrchi15xKiVNAtKOujDkgStaa03CXTqgwP 3+U7A2pTYngiVVHxGchEwmMP11VoeZXPE+WnXPvGU2Unt8up0ag8H2lT3uH2kAOc o4iPbMkghLQE3V2soZ4ByawCohwONVB47rQlCYofOL1Qog3DqYAD588JD/gLN0D7 5f6HacmuHxrviArCwzdy4PmA4VLxgGKZ8jOGjIn9HUV0Mxr2ncTAoo/trIlg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1705350589; x=1705436989; bh=mfvxTqywSwQPpZIAHcZQJci945Rw dVqo25EbQJY/r/U=; b=MDk49SX4uEehA4IQTEdzNYYmixwqkpfb+tF+VvESiYfT ByMgOtIHyoSBc/WJkjHSO6eH51E2iaGyLuSYazJDyWuLul+k2B3DG2APxkLPTYfV U54V3JfRXhKQdb6Ci6tnYj54QpTvLBcpQoyV/NVqCxF5KLNFFNoqJ+gq4Z3vPQ7T 4oU0EULWVShFUePr3JQGGXKYjaUvLovvA7XbFWbk62Ve1ozdUynYTbefK57OiDuK PwvlFQCgP+5QONe4aeMf1kGHAwYjYc48MBlFk+rBEpJv1vksCFMxFtWuFx7Y1BDo dRLNukfOhFA9K3I2aCGImGJdc5SImCpC0g5m0JXpzg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdejuddgudeflecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdet rhhnugcuuegvrhhgmhgrnhhnfdcuoegrrhhnugesrghrnhgusgdruggvqeenucggtffrrg htthgvrhhnpeekheetgfduvdeljedvieelieffhfeuveegvdehieduhfeuvefgheekieet udekkeenucffohhmrghinhepshhouhhrtggvfigrrhgvrdhorhhgnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghrnhgusegrrhhnuggsrdgu vg X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 37DFBB6008D; Mon, 15 Jan 2024 15:29:49 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-1374-gc37f3abe3d-fm-20240102.001-gc37f3abe MIME-Version: 1.0 Message-Id: <6979c914-64ef-4d86-bd37-9cc787fde9bf@app.fastmail.com> In-Reply-To: References: <877cka7m09.fsf@oldenburg.str.redhat.com> <111c4bfb-bc58-412e-9a37-a5c2ed7f0e3c@linaro.org> Date: Mon, 15 Jan 2024 21:29:27 +0100 From: "Arnd Bergmann" To: "Adhemerval Zanella Netto" , "Florian Weimer" , "Antonios Salios via Libc-help" Cc: "Antonios Salios" , "Jan Henrik Weinstock" , =?UTF-8?Q?Lukas_J=C3=BCnger?= , "Rich Felker" Subject: Re: 64 bit time_t on riscv32 Content-Type: text/plain X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,KAM_NUMSUBJECT,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, Jan 15, 2024, at 21:15, Adhemerval Zanella Netto wrote: > On 15/01/24 16:55, Adhemerval Zanella Netto wrote: >> >> >> On 15/01/24 10:40, Florian Weimer via Libc-help wrote: >>> * Antonios Salios via Libc-help: >>> >>>> According to a kernel maintainer, the __USE_TIME_BITS64 macro should be >>>> set on architectures that use 64-bit time [2], otherwise the kernel >>>> headers will not be able to pick the correct definition. >>> >>> __USE_TIME_BITS64 is an internal glibc macro. It is not used on >>> architectures which have a 64-bit time_t by default. >>> >>> Surely the UAPI headers know which time size the architecture uses in >>> the kernel interface, and can be written arcordingly? >> >> The use of a glibc internal definition on a kABI header is not really >> a good design. This seems to be only user so far, so I suggest to fix >> on the kernel to not tie to a glibc internal definition. >> >> CCing Rich from musl that most likely would want to see this fixed. The >> Android developers might be interested. > > So Arnd raised it was the agreement when it was added 2018 between glibc and > kernel headers, and we changed the deal three years later. And not sure if > it was on y2038 draft documentation, or on the initial patchset. Nor I > recall the discussion where it was accorded (Arnd could help me here). > > And I am not sure this is a good design, it ties glibc internal definition > to kABI meaning that glibc won't be able to refactor this code because it > might eventually break the ABI. I think we will need at least to proper > document this somewhere to avoid future breakages. It's in the design document and was added in https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?action=diff&rev1=86&rev2=87 which was all we had to work with at the time. I understand that some aspects of that design changed over time, but I didn't know this one did. > For glibc side, I think we can always define the macro so the check would > be '__USE_TIME_BITS64 == 1' for 64 time_t support. It would require some > internal refactoring, but it should be doable. I took another look at the input_event definition now, and I think we can actually change it to remove the __USE_TIME_BITS64 check in this one, dropping that 'timeval' reference from it, since it was only added here to prevent compile-time errors on architectures that use the traditional types (all 64-bit ones and 32-bit architectures with time32): struct input_event { #if (__BITS_PER_LONG != 32 || !defined(__USE_TIME_BITS64)) && !defined(__KERNEL__) struct timeval time; #define input_event_sec time.tv_sec #define input_event_usec time.tv_usec #else __kernel_ulong_t __sec; __kernel_ulong_t __sec; #define input_event_sec __sec #define input_event_usec __usec ... }; This is probably ok because by now most users of this structure will have been fixed to use input_event_sec/input_event_usec instead of time.tv_sec/time.tv_usec. Anything that has not yet been changed will now also break on 64-bit targets. The sound/asound.h header is much harder to change: Removing the __USE_TIME_BITS64 check here would require using the new-style ioctl commands everywhere, but anything built with that new header would break when running on linux-5.5 or earlier. Arnd