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=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 106AA1F461 for ; Wed, 17 Jul 2019 16:04:51 +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:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type; q=dns; s=default; b=e96YX +4iEpk418SGw/Ad2dvN6DAsh8lRMWsTYwPcFtro6sBuIiDWaeJGuzWkMj9dJmnV6 nf2VzLzapTq8fuZkj6LGv+RcKl1dIVG2lGp1UJWXtJCCZd9WCf1V993aJL/JZB9x +l9DtyrBFpn7gbdfuFd0OGSd4zvq2vpD4v57dM= 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:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type; s=default; bh=qUYP0lQDcQo 2EeATlkF1igQsnOM=; b=ET4lWpN87TOUrE9yq2xQKlWKQ8zfjFtiITiYLPXT+Qq mNjzDru3nHn1OQHsl//7flqx8UcRaDRU+Z1PMbYEY022ItX08BA2IlzamJPMKOgA pRzWa05DHB026IUQpeoEG16PQOMsutaNDzazXHYrbtBsYPm8ZUnqob3pXcUhLR20 = Received: (qmail 83648 invoked by alias); 17 Jul 2019 16:04:49 -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 83638 invoked by uid 89); 17 Jul 2019 16:04:48 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mx1.redhat.com From: Florian Weimer To: Wolfgang Denk Cc: Arnd Bergmann , GNU C Library , Lukasz Majewski 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> Date: Wed, 17 Jul 2019 18:04:44 +0200 In-Reply-To: <20190717160021.75EB224003E@gemini.denx.de> (Wolfgang Denk's message of "Wed, 17 Jul 2019 18:00:21 +0200") Message-ID: <87h87k7ilf.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain * Wolfgang Denk: > 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... 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? Thanks, Florian