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 BB72C1F461 for ; Fri, 19 Jul 2019 03:06:54 +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:references :mime-version:content-type:in-reply-to; q=dns; s=default; b=fiL0 1oKDiOgzALV8O3z4rqUBpBZhS8HTfzasN2E2US9SNGpPY/+tRVzJ364tQQ0cCiCW WkkxtHIbhCvPZs4hImbygcwZKE66yV4F1DddClarn33x+hsfsBymTDilfc+jAwXF 0UDPSheAn39rauoc3AQr09r3IJmziDr2RnW1Cck= 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:references :mime-version:content-type:in-reply-to; s=default; bh=gklLc61wF/ DOCNVhRCvNuBGKefo=; b=EP4qNnt4anR50gn0Yw9bIrU9/JLr+hUIqgX4Wv73CE PrMDVrE0skh4MmRJXunq7H8fDNzLvTPIgFlwCIrv5cBS7mZCuqn00YvhkLERtIfR 7vQLTcl1H56iLaa8oslS5uvkKLX1JxACXqf7bRcdyXkHDxFnz0iPHqBGyh/N96fl w= Received: (qmail 115205 invoked by alias); 19 Jul 2019 03:06:51 -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 115182 invoked by uid 89); 19 Jul 2019 03:06:46 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: brightrain.aerifal.cx Date: Thu, 18 Jul 2019 23:06:39 -0400 From: Rich Felker To: Adhemerval Zanella Cc: Florian Weimer , libc-alpha@sourceware.org Subject: Re: Accelerating Y2038 glibc fixes Message-ID: <20190719030639.GV1506@brightrain.aerifal.cx> References: <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> <87ftn3xija.fsf@oldenburg2.str.redhat.com> <0a59e20b-e941-e71a-5d4c-cda8088617c3@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0a59e20b-e941-e71a-5d4c-cda8088617c3@linaro.org> User-Agent: Mutt/1.5.21 (2010-09-15) On Thu, Jul 18, 2019 at 05:31:51PM -0300, Adhemerval Zanella wrote: > > > On 18/07/2019 16:13, Florian Weimer wrote: > > * Adhemerval Zanella: > > > >> 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 > >> build with a minimum kernel of v5.1 (if I recall correctly as being the > >> one that added time64 support)? > > > > Does this mean that some developers see a glibc 2.31 with a 32-bit > > time_t on i386, and others see a 64-bit time_t? > > > >> It will move all time32 support as compat symbols for the required ABI, > >> without an option to select it through a build flag. Newer ports will > >> just have the expected symbol names, no tinkering needed. > > > > But if we build glibc with pre-5.1 kernel headers, you will get the > > legacy interface? > > My idea is to setup based on --enable-kernel and add a new EI_ABIVERSION > when time64 is used. So, depending on how glibc is built, developers > will indeed see a different time_t. > > Legacy builds won't build any time64 support, even with newer kernels. > Build set with --enable-kernel will automatically set time_t as time64 > and redirect the required interfaces to the new symbols ones (similar > to LFS, but transparently as _FILE_OFFSET_BITS=64 as being set as default). > > Newer 32-bit ports won't require anything like this as expected. > > I still think that in long term this initial bump transition is better > than to the complexity from mixed support. I see no reason for it to depend on the minimum kernel version glibc is built for. You should be able to build glibc that runs on the oldest still-supported kernels and that uses 64-bit time_t in the application-facing ABI. If built with --enable-kernel new enough, the fallback code to use old syscalls when the time64 ones fail with ENOSYS can be omitted. If not, the time64 syscalls are tried first, and if they fail, the old syscalls are used and the results converted. This is what musl has always planned to do regardless of whether we go with a hard ABI break or symbol redirection. "Only works on bleeding-edge kernels" is a sure way to make sure nobody uses the new thing, resulting in continued production of legacy binaries that are ticking timebombs far into the future, and all the exploding popcorn when 2038 approaches... Rich