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 13F811F461 for ; Thu, 18 Jul 2019 18:53:38 +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:references:from:subject:message-id:date :mime-version:in-reply-to:content-type; q=dns; s=default; b=xBS5 dEUxx3zMo0nqm+5oEq5KyTP9Mp7FYssuB2zBr7Wz9kskkmJZRkwX6rtgGACLVkpO 7Ga2M8Xkiel4tGxTvSnr79UikC1dqkcKfpV1NpSEn7GruShukn0AXd7DD4auQMfh Xn9d75n8vxtrvKAtdtTuo5mwbr7V3/7XOnIQ5js= 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:references:from:subject:message-id:date :mime-version:in-reply-to:content-type; s=default; bh=rV5+paRFn3 WGWG52zyMri8QUx7g=; b=E4MKgn/MJ9pETKWcFxcSUW7ZQ/OhcXvk0IhmL+x8gb 9fe5MJ8s2VQUOugxmAeMA5O2dLcqpMMaMajycPnmBN+ZQNB/E3Qy3a9nj1z7KAa4 zDXM1dyYhGBMh8CNGPkgwOaBd+hhfYuwNaSvciGAEn5mBLiuEoWWOmr6EL2KQail A= Received: (qmail 83819 invoked by alias); 18 Jul 2019 18:53:35 -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 83811 invoked by uid 89); 18 Jul 2019 18:53:35 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-qt1-f194.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=to:references:from:openpgp:autocrypt:subject:message-id:date :user-agent:mime-version:in-reply-to; bh=wVNvH/Aet3XgEvv2pzE0y4i54MyxNxN9JSLPkcNOazo=; b=zUacY92lWE5mqDD0YEx4CJEB4urhvKf7v6gYOnE6TpUxPKyd73ug1BeC55R3JmEN/A +qkmF6uoTAVPA/GIuzAQA+me5XlOOvoh1TGHcS665pC+0DsLW9azzU4t9ODWauE9vALP AbSrytmLnNYIDkggJlGzLxf8DJxBMTV7GvGrp/CH4JUJ7r04aBu7prgkQDXHYKukcXgk GLR1TZ232mj80FZzMoohjKmnoKQwtD2GkYSAK9Ki8VcZ89gu33bX98P1XRw+eIeBMEqk Tqfbh4PkxtziW00UTgz8YdSmly9wEPjfRrVMVJH3OWpPdaSJ8h2W0z78Hhl0tPa/DH6w UfZA== To: libc-alpha@sourceware.org References: <20190712072103.D3DBC24003A@gemini.denx.de> <874l3mjgi6.fsf@oldenburg2.str.redhat.com> <20190716145216.1C7CE240085@gemini.denx.de> <875zo0911b.fsf@oldenburg2.str.redhat.com> <20190717160021.75EB224003E@gemini.denx.de> <87h87k7ilf.fsf@oldenburg2.str.redhat.com> <20190717181811.5902cd5e@jawa> From: Adhemerval Zanella Openpgp: preference=signencrypt Subject: Re: Accelerating Y2038 glibc fixes Message-ID: Date: Thu, 18 Jul 2019 15:53:28 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20190717181811.5902cd5e@jawa> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ruKFpWJiDjYTPcPJdW8XZuI3cNPCrU6Pe" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ruKFpWJiDjYTPcPJdW8XZuI3cNPCrU6Pe Content-Type: multipart/mixed; boundary="HTsRLFPBbBq7dAUnZfgefwOV7nvcuT3NA"; protected-headers="v1" From: Adhemerval Zanella To: libc-alpha@sourceware.org Message-ID: Subject: Re: Accelerating Y2038 glibc fixes References: <20190712072103.D3DBC24003A@gemini.denx.de> <874l3mjgi6.fsf@oldenburg2.str.redhat.com> <20190716145216.1C7CE240085@gemini.denx.de> <875zo0911b.fsf@oldenburg2.str.redhat.com> <20190717160021.75EB224003E@gemini.denx.de> <87h87k7ilf.fsf@oldenburg2.str.redhat.com> <20190717181811.5902cd5e@jawa> In-Reply-To: <20190717181811.5902cd5e@jawa> --HTsRLFPBbBq7dAUnZfgefwOV7nvcuT3NA Content-Type: text/plain; charset=windows-1252 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 17/07/2019 13:18, Lukasz Majewski wrote: > Hi Florian, >=20 >> * Wolfgang Denk: >> >>> Dear Florian, >>> >>> In message <875zo0911b.fsf@oldenburg2.str.redhat.com> you wrote: =20 >>>> * Arnd Bergmann: >>>> =20 >>>>> b) Those that already need support for 64-bit time_t because >>>>> they are deploying new 32-bit binaries that are expected to >>>>> run beyond 2038, while not caring at all about compatibility >>>>> with existing binaries that are already known to be broken >>>>> for this purpose. =20 >>>> >>>> There is also c), new 32-bit architectures which need 64-bit time_t >>>> support today due to kernel limitations. Whether those binaries >>>> need to run for two years or twenty does not matter to them. >>>> >>>> I have reviewed patches for the c) case, but that doesn't seem to >>>> be work that interests Wolfgang. =20 >>> >>> Correct - our situation is Arnd's case b). >>> >>> But my understanding is that for c) glibc has to modify the generic >>> syscalls wrapper (like clock_gettime/nanosleep/settime, etc.), and >>> for b) we also need to do that first. But currently we are stuck at >>> the point where the __ASSUME_TIME64_SYSCALLS flag is not accepted / >>> pulled. >>> >>> So b) and c) align in development... =20 >> >> Can you do without __ASSUME_TIME64_SYSCALLS? Most other __ASSUME_* >> macros are an optimization, and if your interest is b), >> __ASSUME_TIME64_SYSCALLS will not be the default for glibc >> distribution builds anyway because defining it would negatively >> impact host kernel compatibility. It's not just about containers in >> the fashionable sense, but simple build chroots are problematic as >> well in this context. >> >> Or have you received different guidance that __ASSUME_TIME64_SYSCALLS >> markup is absolutely required for the initial contribution? >=20 > The __ASSUME_TIME64_SYSCALLS was discussed with Joseph and Stepan (both= > CC'ed) for a long time on the libc-alpha mailing list. The discussion > can be found here [1] (last link is the newest one). >=20 >=20 >=20 > As fair as I understood from the previous discussion, adding > __ASSUME_TIME64_SYSCALLS is a first step to add Y2038 support (or 64 bi= t > time support to 32 bit archs in general). >=20 > The latest patch (v8) with semantics explanation of > __ASSUME_TIME64_SYSCALLS: [2] > =20 > Note: >=20 > [1] Evolution of __ASSUME_TIME64_SYSCALLS up till v7: >=20 > https://patchwork.ozlabs.org/patch/1092579/ > https://patchwork.ozlabs.org/patch/1096343/ > https://patchwork.ozlabs.org/patch/1096349/ > https://patchwork.ozlabs.org/patch/1097132/ > https://patchwork.ozlabs.org/patch/1100097/ > https://patchwork.ozlabs.org/patch/1107125/ > https://patchwork.ozlabs.org/patch/1114061/ > https://patchwork.ozlabs.org/patch/1117100/ >=20 > [2] - https://patchwork.ozlabs.org/patch/1117100/ More and more I see that a possible disruption in a release due to a=20 possible ABI change should be a net gain over time by moving to a better alternative. The off64 migration required a lot of efforts and its=20 issues still hit us in a way or another (BZ#23960), especially because=20 off64 is *not* default for 32-bit builds neither on new 32-bits ports=20 (on glibc side). Even now, from BZ#23960 comments, it seems that=20 distributions still do not use LFS for some packages builds, it required = Linux to force us to move forward. So what about to not add a user-selected way to set the time_t size (as off_t) and just enable time64_t support and sets is as default for=20 build with a minimum kernel of v5.1 (if I recall correctly as being the=20 one that added time64 support)?=20 It will move all time32 support as compat symbols for the required ABI,=20 without an option to select it through a build flag. Newer ports will just have the expected symbol names, no tinkering needed. And yes, it will mostly break stuff once people start to build distributi= ons=20 with these options. However, it will save us time to figure out all the b= its and joints required at cost of an initially high cost of adaptation plus the all required code complexity and testing to support the multiple=20 permutation possible. I also wish we could also move forward with off_t and set LFS as default as well. =20 --HTsRLFPBbBq7dAUnZfgefwOV7nvcuT3NA-- --ruKFpWJiDjYTPcPJdW8XZuI3cNPCrU6Pe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEUMEGt8/rO2QSpplaqrHsFKeUiO8FAl0wwCgACgkQqrHsFKeU iO80Pw//WjueqHjF09JuTHD+YLgVgf5ot1PTtfKJzrCzgFbZ/9BPrag8fnJEPETf 5AH/yfwKcJHmNA1tIfGURXT4PuAItfI81a2K7QgRsgorn2AmyCPCs+eG+CV0zuux 4qysiPBjSx+NcgnHcueTIMt1P83yLvvUIB4OIp8B9tm6SrOcXZV0iZHsnikP0tgS +8PZB18kxNuKWjllosJv43WNL3snBj+VfwAEe4caZOD9Jwy6inm0cwNDARLVxyA8 0GGtR3ZgqU452uC/mZT/ECNL1G/oWilRSUqXuperMNA8/IgLWKb2aL6G+PGi5bxa klIpW8i/qMz91DsM1IDUFWL1a4gPofoSQny1YlCpcPTVAqOLjLZGxl3vTu4bTuMv AvpmP84rTlrpAzYuiiAScHsFBhWoV7FDyU/JBB7+MFUFi2AlG6ZvlVRzJcEnAiN0 pkbGxPFmkAP584waPgcWPDgbmR5J4sHgOYRj3vR0psEP2Oe+NGhSkA7jRYJAUFIq 9ZZyWyJXmRSjCbWPVt1OE9lyvlCAjGIVVCRPI58bb3hNDbwa6WpEHnvZPk1WkMdN qwnkub0JweKlVVlglhxB5aR3BWaI5uSNk4gFkbovlFk9u3SNlWzbYWiXppxTiP3I DEwXgmr5Yah+nwUMsXL6HGrT49Ha9DprM7d/Uo0rhDC2cf6GF4Q= =atXM -----END PGP SIGNATURE----- --ruKFpWJiDjYTPcPJdW8XZuI3cNPCrU6Pe--