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 BFB201F466 for ; Tue, 7 Jan 2020 20:23:16 +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:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; q=dns; s=default; b=STr2 mLOse6DkR8kR+NjfcgcgUPnD6homPpoxJlyjmcbgi59kUdEZ0NFHenqecKyaYbnw iijjYUpEXPiVczBnAZBXEEHFiYsOIRhTmWbzyV4TRXMBK1q2dbQvdesDPaPbWfMY CiYHrSMvbbAG+o3hkELPUqEFwEgjgWoOKewOCnE= 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:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; s=default; bh=hx5FRtxcZ6 XiOJCgMpdyrQzKASY=; b=ubZesGcwQmDpTHE8rLX2CToOC6q8/dOs4bh91ecqOb nslPuQsgUBFOdHR/CQwyxGp6cQ8gP9ZqVqDLIUB3XPCtvLGsA8ZuoBe2sy01GmeV roRqGKcJH8wf7z00eTY5uOOtzUw+QBb5NDwOpf75bFo1UzGuHVsM1eGl2yGH8Xq+ o= Received: (qmail 10632 invoked by alias); 7 Jan 2020 20:23:14 -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 10624 invoked by uid 89); 7 Jan 2020 20:23:14 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mout.kundenserver.de MIME-Version: 1.0 References: <20200106121742.1628-1-lukma@denx.de> <20200107102752.396f7f6f@jawa> <20200107152521.7416d5f3@jawa> In-Reply-To: From: Arnd Bergmann Date: Tue, 7 Jan 2020 21:22:52 +0100 Message-ID: Subject: Re: [PATCH v4 1/2] y2038: linux: Provide __timerfd_gettime64 implementation To: Adhemerval Zanella Cc: Lukasz Majewski , Joseph Myers , Paul Eggert , Andreas Schwab , Alistair Francis , Alistair Francis , GNU C Library , Siddhesh Poyarekar , Florian Weimer , Florian Weimer , Zack Weinberg , "Carlos O'Donell" Content-Type: text/plain; charset="UTF-8" On Tue, Jan 7, 2020 at 9:16 PM Adhemerval Zanella wrote: > On 07/01/2020 11:25, Lukasz Majewski wrote: > >> 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. We currently try to enforce it through review since the introduction of the automatically generated asm/unistd.h header files, but his has already failed one time for the recent clone3 system call that accidentally was missing on one architecture. I have some plans to enforce it using tooling, but it should at least be a safe assumption that all new system calls have the same numbers across all architectures and are added at the same time. I also have some vague plans to automatically generate not only the asm/unistd.h header but also some trivial wrappers around syscall() that provide an inline function with the correct arguments, to allow calling any syscall without relying on libc to provide a wrapper for it. Arnd