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,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,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 2C3661F463 for ; Tue, 7 Jan 2020 20:17:00 +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:to:cc:references:from:subject:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=Z9yneVO1PzIU7X2Z I0qxmxrtdm+RgEJ4Qyq/icSM/QXNbxFrDqok851zrvsWvHnAXIoenJDMBIkYv5NP snjldfju/330M7zlR0qllt/QP/rT0xPDt1IDvEOWzlHz74BcAZlFECWhTd2HJ4Zu dUuFJ97FTT8x1erpOHl/XNDxwSg= 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:to:cc:references:from:subject:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=q5iwMX21mT/8/eRWwQvOaa oT5/Q=; b=CIXY4WvtNiFohAiWkmAcD6BkedN36EvfU7lpC+jAwuSYnGwy6qvRHb /sRoCc4vKI5Blj7m1UHCdbeYNz2Swi9llG7/llLmYtPl8KuBg3GbA+xjiynlL/p2 XJ4EQIIOOqoO7zlQf1rQQSh1HEAvd9L8FfFAZCg+CKSdyfMxKM3Rs= Received: (qmail 5072 invoked by alias); 7 Jan 2020 20:16:57 -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 5061 invoked by uid 89); 7 Jan 2020 20:16:57 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-qk1-f193.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=to:cc:references:from:autocrypt:subject:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=yAAwqAGXmELEoeK5GL6kfVw11Oj5NFRUZ5n+BFW0eAk=; b=K0vhaxOiRFQvmpt5W+mFxijHnC2xkPUFFHfyeI6196Mifb+eWPH/uWlK2tqCYU8Uwj 8RXVGCHJZlvmNlIa+g2PdvMPUx4GRdxSZN/bPUa1XNtKfC/YLAwT511k1MCh6baF18C0 eo+yPFOHOMfR6+V9SmxRW8TslrwOEZAIVndy3chDZbud1HPSchIDi+hfr4rd39D1KeJY Z63e89LKEXKNXoBRPtO8PCecP8aLzo01cSuNKCLmhWeriXPoKUgF/G5ri0888wgDp/7u Y0HbBjqnATcYpoBUjbHzYg+yuko5hoNQGYlbtuai93cyz9kJnFrzAUyNw1uxnSXYNiYv zz8g== To: Lukasz Majewski Cc: Joseph Myers , Paul Eggert , Andreas Schwab , Alistair Francis , Alistair Francis , GNU C Library , Siddhesh Poyarekar , Florian Weimer , Florian Weimer , Zack Weinberg , Carlos O'Donell , Arnd Bergmann References: <20200106121742.1628-1-lukma@denx.de> <20200107102752.396f7f6f@jawa> <20200107152521.7416d5f3@jawa> From: Adhemerval Zanella Subject: Re: [PATCH v4 1/2] y2038: linux: Provide __timerfd_gettime64 implementation Message-ID: Date: Tue, 7 Jan 2020 17:16:42 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20200107152521.7416d5f3@jawa> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 07/01/2020 11:25, Lukasz Majewski wrote: > Hi Adhemerval, > >> On 07/01/2020 06:27, Lukasz Majewski wrote: >> >>>> As a side note, now that arch-syscall patch is upstream should we >>>> assume that for !__ASSUME_TIME64_SYSCALLS the >>>> __NR_timerfd_gettime64 should be defined (meaning that Linux >>>> supports time64 for all 32-bit architectures)? >>> >>> Only Linux version >= 5.1 supports 64 bit time on archs with >>> __WORDSIZE = 32. I do guess (but I may be wrong here) that the >>> arch-syscall is supposed to reflect the exact syscalls provided by >>> kernel headers used for building (to help with validation of Y2038 >>> patches). >> >> The arch-syscall is now autogenerated from the latest kernel release >> defined in build-many-glibcs.py. So the question is whether Linux >> support and enforces time64 support on all and future 32-bit >> architectures or if there is still some missing ones (as it has >> happen on some syscall additions, where some architecture lag >> behind some releases). > > This question would be best answered by Arnd (CC'ed) IMHO. From what I > know all 32 bit architectures gained syscalls covered by > __ASSUME_TIME64_SYSCALLS from Linux 5.1+. > > The arch-syscall seems to me like a mean to test for example the time > related syscalls which use different versions (32bit time vs 64 bit) on > different archs. Notable example - clock_gettime(). Am I right? The arch-syscall is a way to decouple the build from the kernel header used on build, which might simplify the logic to use some kernel features. On the clock_gettime, for instance, as Arnd has indicated we can assume that __NR_clock_gettime64 will be always presented for !__ASSUME_TIME64_SYSCALLS. It would be interesting if kernel also could enforce that new generic syscalls would be wire-up, or at least the syscall number reserved; once a new generic syscall is introduced. It would simplify the __ASSUME_* macro, not requiring the arch-specific overrides on some architectures. > > The __clock_gettime64 is going to be exported (as clock_gettime > redirection) on 32 bit archs which are going to be Y2038 safe (with 64 > bit time_t). > >> clock_gettime64 would be suffice (with a {weak,strong}_alias). >> > > The internal in-glibc usage (calling) of clock_gettime() shall be > replaced by either __clock_gettime64 or clock_gettime64. I would prefer > the former as it reflects that it is internal function (with __ prefix). It required to be the former because we also need to take in consideration linking namespace pollution. > >> However I do think we should fix it to avoid such confusion why there >> is a hidden_proto and not a hidden_def. > > +1. Ack, I will send a patch.