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,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 6C8FD1F463 for ; Tue, 17 Sep 2019 16:51:17 +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:in-reply-to:message-id :references:mime-version:content-type; q=dns; s=default; b=nA8wY KdNbTP+PVIl40t0V2QsbP8p7Iix+WjX64FcrKqZQ6p2e6QoxkReN0OECayaBBVl2 hl4xcQnRsE/aagP5bSuGVObBTI7fTIx48TnG1bOgJOGCW+H5lpGyOel7B/4bNEmL 4BgN6LDsWTclElD2RwWQ70A6kZShBgATBTNpPU= 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:in-reply-to:message-id :references:mime-version:content-type; s=default; bh=4HHZcyxdW8m HXo/+K3J5WYy+e68=; b=SSRzvFpGhBiu1pE8GIrkqvG9+uC7pJKiSVxQp6l/MBj k+3lNZoAvqEiOx2duRryh9mp6MlZEsKLbd7I03jCgGz93QmbdmgykCXtA8yX06Zs BYAGDLIDmnCHusIPsJ/pq4At7nh6F/MAsOYdKQfFlMdNG7cG6Idsp9k/XP1+UuAQ = Received: (qmail 41159 invoked by alias); 17 Sep 2019 16:51: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 41151 invoked by uid 89); 17 Sep 2019 16:51:14 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: esa1.mentor.iphmx.com IronPort-SDR: WE81bqPIvLevarp72eQgxhaVPj1HbNQ7gt0U2wYokgzDALDLjaQdAvz7ab4aWj4xUt2E+fxzRA MowHxE9PctaeWTqJgOyflcYd26jfKEi/i50oYOhy5nM4uNyDQjHtn1PZgi466ft2zypk1REt8J vq+CTGNcJWOUazm3QCIlPtBmLTqLRfW7lb2ulC4FPA7uoog3Met3kYc3J4JaxmFMoSASdLiBMA poqt/0mD/+DoGCpVfJgZkkg7vHFGJzmCMtkI/DVFfwqmzmDL5Q4IX9fjxEAkXLqOCchAe5eFqX ugQ= IronPort-SDR: cQ2b1e1O+4ZvuNOsICP/QYfRAXHpNQQLVg0IgiAgc1r+1pCTkyDhy0KzU6whMoQbrWuQQKRVhi aYAbbWwIZYG2sxAevEuGokOXpctUePtxuo/Nk+aRuf+WFU3+21rczsSzVgGoiO8XEzdMsW2o3U 2lbbvacVRZvdLe8ZoSkLPRgll7VndfZ1glvdEbb5sjE3Wsl+QlHDXLDRfbRZ00UBSVXw0pCQ0P 06pO+vJtMetHoDSdKTzvnyoL/nsgg1AHw21gaJ+vCmlgcIps5irk5sDqdfih0coEU8Vj7oR2p2 vw0= Date: Tue, 17 Sep 2019 16:51:06 +0000 From: Joseph Myers To: Lukasz Majewski CC: Alistair Francis , Zack Weinberg , Arnd Bergmann , Alistair Francis , GNU C Library , Adhemerval Zanella , Florian Weimer , Carlos O'Donell , Stepan Golosunov Subject: Re: [PATCH v7 0/3] y2038: Linux: Introduce __clock_settime64 function In-Reply-To: <20190917175343.01715554@jawa> Message-ID: References: <20190906145911.30207-1-lukma@denx.de> <20190917121151.01629dad@jawa> <20190917175343.01715554@jawa> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" On Tue, 17 Sep 2019, Lukasz Majewski wrote: > - New 32 bits glibc ports (like RISC-V 32) will get __TIMESIZE == > 64 (__WORDSIZE == 32) and no need to define the -D_TIME_BITS=64 > during the compilation. They will just get 64 bit time API support > from the outset. Yes, at least if such ports wish to use 64-bit time; I don't think we've really discussed if we want to *require* 64-bit time for future ports (e.g. the next revised resubmissions of the ARC and NDS32 ports). Certainly the work required right now for ARC or NDS32 to use 64-bit time would be significantly more than the work for RV32 (because they also support older kernel versions without the 64-bit-time syscalls, so all the Y2038 work for fallback at runtime to older syscalls becomes relevant), unless they decide on 5.1 or later as minimum kernel version. > - Already supported 32 bits architectures (like armv7-a with __WORDSIZE > == 32) will keep __TIMESIZE == 32 and require -D_TIME_BITS=64 for > compilation. Yes. > After glibc sets the minimal supported kernel version to 5.1 and all > conversions for syscalls to support 64 bit time API are done the > __TIMESIZE will be set to 64 and -D_TIME_BITS=64 will not be required > anymore for compilation. No. __TIMESIZE means the size of time_t in the unsuffixed ABIs in glibc, not the _TIME_BITS-dependent size of time_t in the current compilation. We hope in future to make _TIME_BITS=64 the default and only API supported for new compilations (which is independent of what the minimum kernel version is), but __TIMESIZE would still be 32, because the unsuffixed ABIs would remain compatible with existing binaries using 32-bit time. > Ok. So then we shall keep the condition: > > #if __WORDSIZE == 64 \ > || (defined __SYSCALL_WORDSIZE && __SYSCALL_WORDSIZE == 64) > # define __timespec64 timespec > #else No. __timespec64 should be defined to timespec whenever __TIMESIZE == 64. The timespec to which it is defined, in the public header, would gain padding. The condition #if __WORDSIZE == 64 \ || (defined __SYSCALL_WORDSIZE && __SYSCALL_WORDSIZE == 64) is correct as a condition for struct timespec (in the public header) *not* to have padding. -- Joseph S. Myers joseph@codesourcery.com