From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by sourceware.org (Postfix) with ESMTPS id 92E063858D1E for ; Mon, 15 Jan 2024 20:15:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 92E063858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 92E063858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::634 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705349721; cv=none; b=Ny7t/sdLTv/mKOE25G+h/jayGC+LUVi42MFLhdTe8j66lGUWym5IPiSW2hLS995C3yQ+r2yLhyWi6h7Bua8TkIJdQjB3S4jsHAlmvJjBy6L1oUzWCO3KEqjSwUNap3pvl9efS7cbAriZnkE6QEZ0ZpecjWqx/ooJbWPUbk53BBE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705349721; c=relaxed/simple; bh=vfLYN1FMR7ZPLXoM8OM+vIp0a061niouEqUz8nR8VMo=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:From:To; b=AtHz9Ok8C8h+dJt9JiyE42c0rdjNNB7IfYoa+R+4NFWzQXTlefI33n4BovpkG6gDBjGPpyCJbFLPfhFe6iqNKvOaPNRuIcvPljKKuouc7YGtOTsuks7KudnnoKMTnWg4jLlFfT5ta68F6Chi35wvviYPs3DiO7JVAUIkaR6Ao1c= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-1d41bb4da91so49901205ad.0 for ; Mon, 15 Jan 2024 12:15:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1705349717; x=1705954517; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:organization:references:cc:to :from:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=rjglfXnb5KNHcGxMoXbN+WPkJ9QCy3N1e4sNbN13wRA=; b=IxsZnvCPKfRic7HCCQeuAktj5v5y4BMa/u8LZNQp0pi5s+AIGaNdCNSAcRxERnEVZx Nx0d/1zWiJtF9KRjqahoU6XE79DMTGI0HkP9r+qSLUN77Jr2CLfYzeFDO28Cv4nYZvKt b06LzjNReIutHnEHZ/b/ya23J1pz90ZM+4am/7A7ch3AhhWDzG0eHcvOYMEHnPqdFTGV xCZ5Ug7M4joN4Rmz/I1NlG0Jan6LGANWFMSRZijCePzAFHiOewOu4z84OvQlfKyTmqTo 2uG5v1+ulDFjJiuEv1C5klkhdTiCqQPvUYm/EIrOlMXFaP36cX8ORFuO/Yl8QUjeNYkt TY6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705349717; x=1705954517; h=content-transfer-encoding:in-reply-to:organization:references:cc:to :from:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rjglfXnb5KNHcGxMoXbN+WPkJ9QCy3N1e4sNbN13wRA=; b=qDGM/GRMp6a04UnPF2jmGRppTxzQmbf868ZdMzcILzQmng5luxW2N+aj9UFA/tsRi0 72nul+h/1OwtVD1VrysObS4maAyMDZQD3Z0bHMsU6E0GQvd86YQkkofhDPVGbqn6XZP/ lthwIJ84vztVhWHGmsze9Mt+FlWca1cM/zSpIYqDqWjKZcm6v2cV7n1rZ0mHUkoNRc6a 5iMR8LDX82CvFCiFy8LVh4wTbPdx67JVOD0eEUsFE3yr4rKXMi6JdZ4WNYRpEkk+FGA0 z66gQdTn8qmaLvR0V/1DfLwiV2UiDhIWFep4prkPYF4wy8ktw2qEhbd2yAcQrCJe70+g XGjw== X-Gm-Message-State: AOJu0YxqL+voBQ9kVtVZlli8LYVlCmomnq+HlP+E2sW3NOH9JuWNc9kg IcSxF/tUG8xyROHzOh+UfEa9CA6JWPPm1Q== X-Google-Smtp-Source: AGHT+IFX2PcQtg5QnTW5p8njKG4zoKwd16oKb8OfZ18askBv/6OkyFG4ThLN7wBaYNiC/QtG25wYvQ== X-Received: by 2002:a17:902:ea04:b0:1d5:5c30:9456 with SMTP id s4-20020a170902ea0400b001d55c309456mr3378279plg.65.1705349717637; Mon, 15 Jan 2024 12:15:17 -0800 (PST) Received: from ?IPV6:2804:1b3:a7c2:2787:1d58:abc7:72ea:8c9c? ([2804:1b3:a7c2:2787:1d58:abc7:72ea:8c9c]) by smtp.gmail.com with ESMTPSA id p18-20020a170902e75200b001d3abc86c9fsm7915414plf.195.2024.01.15.12.15.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Jan 2024 12:15:16 -0800 (PST) Message-ID: Date: Mon, 15 Jan 2024 17:15:10 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: 64 bit time_t on riscv32 Content-Language: en-US From: Adhemerval Zanella Netto To: Florian Weimer , Antonios Salios via Libc-help , Arnd Bergmann Cc: Antonios Salios , Jan Henrik Weinstock , =?UTF-8?Q?Lukas_J=C3=BCnger?= , Rich Felker References: <877cka7m09.fsf@oldenburg.str.redhat.com> <111c4bfb-bc58-412e-9a37-a5c2ed7f0e3c@linaro.org> Organization: Linaro In-Reply-To: <111c4bfb-bc58-412e-9a37-a5c2ed7f0e3c@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no 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 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. 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.