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=-4.0 required=3.0 tests=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 69D851F461 for ; Wed, 17 Jul 2019 16:00:50 +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:cc:from:subject:mime-version:content-type :content-transfer-encoding:in-reply-to:references:date :message-id; q=dns; s=default; b=LTBNwT9kCDjeP2N3Jp3qP+rtxaRwzvA G39/9sNbhr9nS8sup52/GDskH1U/20kk6giKxXbO0tZozHBQWfk+8Os8/SGW7T4p qyeZvF1+VZKrclqy+RmoNgf0EqJrxuQDm0Egw/Ow3S/oAVbs7eCHU0+0wh1Cv7EO HjFCJg1T62Wg= 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:cc:from:subject:mime-version:content-type :content-transfer-encoding:in-reply-to:references:date :message-id; s=default; bh=fHwV2VmBN7ekVXdKmx6wN8PIlPg=; b=xJohM Kvft5Xeo5lWEs4orjdYxZZfYkfbcc/yfCHNF4ztI/v/ic75p4WfdX/N0kbalCN/J ZZIFK6oSZVVBCZWsKG+6xx27Q7bSfkgX8XkjBUAQL5caTDPlGpCLUrxdLMgtAkuU EpoSRtlhyLSF/0DLLDPjrg31eG0sJErftHe9sc= Received: (qmail 77923 invoked by alias); 17 Jul 2019 16:00:47 -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 77811 invoked by uid 89); 17 Jul 2019 16:00:39 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-out.m-online.net To: Florian Weimer cc: Arnd Bergmann , GNU C Library , Lukasz Majewski From: Wolfgang Denk Subject: Re: Accelerating Y2038 glibc fixes MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8bit In-reply-to: <875zo0911b.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> Comments: In-reply-to Florian Weimer message dated "Wed, 17 Jul 2019 16:41:04 +0200." Date: Wed, 17 Jul 2019 18:00:21 +0200 Message-Id: <20190717160021.75EB224003E@gemini.denx.de> Dear Florian, In message <875zo0911b.fsf@oldenburg2.str.redhat.com> you wrote: > * Arnd Bergmann: > > > 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. > > 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. 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... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de An Elephant is a mouse with an Operating System. - Knuth