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 B5F331F461 for ; Wed, 17 Jul 2019 16:18:26 +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=qKX1Y cm3CdbVv/pfHU5LOUcJQ1UGt5SY2S/OpCFYSm47PwbCd3eKan9jLRAhrcavbtjPf 7reOkJDOOttz6mu4HJ0Rw1I/9CkICogCGSbE2OkcfbFobAdhzEdJIPjWLmPjoiki xrk5yOCzZpTNgQNuOb4OuixXPgFlYtHs8AZFFI= 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=RaVs/mJOgsh JaDeV+9+VjN4DVNc=; b=kXOdRFAPWSTlRasx+veihUpOsa9DutNY1LBskjfghHu TlkldtgW98bwTVlkNqIhCGHC4P30TIubrLuRKpthxqpC+MNLSD0D3W2LhfFtuDwy O1+Nrq5LGn9CORTiUYK2WoeXiLTikwO6DRqWOS5mYZOljbeZso6jWwCno5FPnsEk = Received: (qmail 100000 invoked by alias); 17 Jul 2019 16:18:24 -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 99990 invoked by uid 89); 17 Jul 2019 16:18:23 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-out.m-online.net Date: Wed, 17 Jul 2019 18:18:11 +0200 From: Lukasz Majewski To: Florian Weimer Cc: Wolfgang Denk , Arnd Bergmann , GNU C Library , Joseph Myers , Stepan Golosunov Subject: Re: Accelerating Y2038 glibc fixes Message-ID: <20190717181811.5902cd5e@jawa> In-Reply-To: <87h87k7ilf.fsf@oldenburg2.str.redhat.com> 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/yuf6LwsNo09.ClDZ4kqeqeo"; protocol="application/pgp-signature" --Sig_/yuf6LwsNo09.ClDZ4kqeqeo Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Florian, > * Wolfgang Denk: >=20 > > 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 >=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. >=20 > Or have you received different guidance that __ASSUME_TIME64_SYSCALLS > markup is absolutely required for the initial contribution? 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). As fair as I understood from the previous discussion, adding __ASSUME_TIME64_SYSCALLS is a first step to add Y2038 support (or 64 bit time support to 32 bit archs in general). The latest patch (v8) with semantics explanation of __ASSUME_TIME64_SYSCALLS: [2] Note: [1] Evolution of __ASSUME_TIME64_SYSCALLS up till v7: 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/ [2] - https://patchwork.ozlabs.org/patch/1117100/ >=20 > Thanks, > Florian 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_/yuf6LwsNo09.ClDZ4kqeqeo Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAl0vSkMACgkQAR8vZIA0 zr24Hwf/fH3ceorlZGmgiZ7EbcRpS8a6oNcwb7Tp8eGi+orL5nCKkNoep/1TWPlC hMzEGgmybn7xhAr6osD8+55auFHGTe9MC+qbyN+RX6HptOkRhxsewecpdEyKBWk0 qKc64ifzoFPBJCDhpZt8fJq/WQQD1rbykMu/MaMDv4XN1r7d79LN+XtirJIKunHF CJTyb/n9+Z8qHyjt4/UXPpGbe2WZo7lbH3PGAvGakjjiTw4an2PaXQQaMb1q9KRV JE1Xa+k8GJUMrqkFKmIaWlp6qvv5td2AiXksEYiUCgZXgdlEed+0JWqBXnoaBaV7 lM33ZV/QXyC8lSW7xt4HWVnVnY0Yog== =G/+W -----END PGP SIGNATURE----- --Sig_/yuf6LwsNo09.ClDZ4kqeqeo--