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 016371F463 for ; Tue, 7 Jan 2020 23:06:29 +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:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type; q=dns; s=default; b=tpBfX 5SwEKks0STfGXfk9CeU8NUwC1L5IUCf1mKUZcqqrD4LmucaPAiyu7QZCR2frkLC6 aKCcbRvWI8adLD5PukTKzEDr4Q+9wdcxKrSNhrRXVVxRbd236GpN5vQFUzHSWdHf 9phvSgERWAMsWXZtqtqzZGGwOQHwkHF4QMXyD4= 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:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type; s=default; bh=R5blh6WXgNh 5E2mQbc/mX0UqyHs=; b=fmeZVW7Cm3IGzbRPEwekJypYy1KyDBlhTLWVqeTcOZV 5Ppbta65Kr/qcTbFfUIZy4ZHXVHiTtaVLqSTSkVCno9+nCqgm7vG06qp6QosXXgd z88U7mh3C2xO/R9iZyH9Y4e82khxl9z9eRsQhHU3J4YlqeyqYCD2RCNPr3ZufXv0 = Received: (qmail 88946 invoked by alias); 7 Jan 2020 23:06:27 -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 88932 invoked by uid 89); 7 Jan 2020 23:06:27 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-out.m-online.net Date: Wed, 8 Jan 2020 00:06:11 +0100 From: Lukasz Majewski To: Adhemerval Zanella 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 Subject: Re: [PATCH v4 1/2] y2038: linux: Provide __timerfd_gettime64 implementation Message-ID: <20200108000612.0cc1bcfe@jawa> In-Reply-To: References: <20200106121742.1628-1-lukma@denx.de> <20200107102752.396f7f6f@jawa> <20200107152521.7416d5f3@jawa> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/LqWvIDqDhFibY+c2uNvLN0O"; protocol="application/pgp-signature" --Sig_/LqWvIDqDhFibY+c2uNvLN0O Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Adhemerval, > On 07/01/2020 11:25, Lukasz Majewski wrote: > > Hi Adhemerval, > > =20 > >> On 07/01/2020 06:27, Lukasz Majewski wrote: > >> =20 > >>>> 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)? =20 > >>> > >>> Only Linux version >=3D 5.1 supports 64 bit time on archs with > >>> __WORDSIZE =3D 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). =20 > >> > >> 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). =20 > >=20 > > 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+. > >=20 > > 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? =20 >=20 > The arch-syscall is a way to decouple the build from the kernel header > used on build,=20 So then we will build against the newest kernel (like 5.4 now). As it was noted in the other thread - this would simplify the build-many-glibcs.py > which might simplify the logic to use some kernel=20 > features. I must admit that I do not see such simplification... Could you give an example? >=20 > 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. >=20 > 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. >=20 > >=20 > > 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). > > =20 > >> clock_gettime64 would be suffice (with a {weak,strong}_alias). > >> =20 > >=20 > > 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). =20 >=20 > It required to be the former because we also need to take in > consideration linking namespace pollution.=20 >=20 > > =20 > >> However I do think we should fix it to avoid such confusion why > >> there is a hidden_proto and not a hidden_def. =20 > >=20 > > +1. =20 >=20 > Ack, I will send a patch. Thanks. Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de --Sig_/LqWvIDqDhFibY+c2uNvLN0O Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAl4VDuQACgkQAR8vZIA0 zr3mlggA55y9ZALi4nG4igfZhdHZt7wuM9901IkHo/cR5DneifQRwGAgyEm/uRyi q4EGaaXz4Vzkj3oKPuT7Q+d+N+RYW3LgAYfcptnEvc9fGWo14BSadCb9rTLOkGHN jrqZOl0YnjonVOuXshrnHFxGDj+9zT4o18ZbQcXWi1UR3T/IXuWYZIZ9cGZcEugh hzQm9jLjY9Okf3OKxSOq+YPoW57khWBh2MDtfZG0Lc92Q94wZYNjtpao+w/L06XI EIH4RFj8AZWYsYMg8buCph9mkkxzDhZoxEphwWU1z50k9M+z58P3AKR7OlORqcrB PIQ0pPW30SJ5VzWbeL6NvbSAD1TLcg== =XUaY -----END PGP SIGNATURE----- --Sig_/LqWvIDqDhFibY+c2uNvLN0O--