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 38F3C1F461 for ; Wed, 17 Jul 2019 14:16:05 +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:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; q=dns; s=default; b=YPpW nN2mPseeR6Lk0rverOxJLY22eaM/k4TYSPU1dVZQprKMGvgpMvfxFUViNIH87Yne +ynap9u7FRq+mXR+kzDr4t/jc4CiQX15FKmPrp8KU0atQP4QvGzovN0FiHAKGHDi KKp2KCq+UnfINHlUFwC9NTTr2q88Y9OwmrhDGls= 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:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; s=default; bh=xd20orZgPz wtv6FgGWeADmQAZ1Y=; b=uGvbKsPfTfrzMEICboLZs8tJo/VWoIGrGhv9ww2dku NFsJTq/e1pxwAd0p5TAiU0mCUvB3BnfxK1BXfo13DYVslzsq75Z07OG1XqvcNtCg 4YXpaEzFGA4cIhhWTfjCAEvmtmVViC11/nhxnukpSY7dfOIymW7icFMf0Gf+cg+N M= Received: (qmail 52158 invoked by alias); 17 Jul 2019 14:16:01 -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 52021 invoked by uid 89); 17 Jul 2019 14:15:47 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-qk1-f195.google.com MIME-Version: 1.0 References: <20190712072103.D3DBC24003A@gemini.denx.de> <874l3mjgi6.fsf@oldenburg2.str.redhat.com> <20190716145216.1C7CE240085@gemini.denx.de> In-Reply-To: <20190716145216.1C7CE240085@gemini.denx.de> From: Arnd Bergmann Date: Wed, 17 Jul 2019 16:15:25 +0200 Message-ID: Subject: Re: Accelerating Y2038 glibc fixes To: Wolfgang Denk Cc: Florian Weimer , GNU C Library , Lukasz Majewski Content-Type: text/plain; charset="UTF-8" On Tue, Jul 16, 2019 at 4:52 PM Wolfgang Denk wrote: > In message <874l3mjgi6.fsf@oldenburg2.str.redhat.com> you wrote: > > > Since I'm opposed to this entire project, I have largely refrained from > > reviews, except for things that looked obviously wrong to me (e.g., > > things that definitely break compatibility with older kernels or > > existing ABIs), but even for those cases, my feedback probably wasn't > > very helpful. > > I can understand your point of view, but indeed this is not helpful > here. glibc is a central resource for the whole FOSS system, and we > are not pushing these changes for a fancy, but because a solution > is needed for a large number of affected projects and products. > > We need to find a constructive way to proceed with this matter. It > will not go away if we try to ignore it. My impression is that we have two mostly separate groups of users for 32-bit user space: a) Those that absolutely require 100% ABI compatibility to run legacy code but will eventually migrate to 64-bit user space, almost certainly within the coming ten years before we really need to worry (too much) about things like key expiration dates beyond 2038. 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. If we just work to satisfy both these groups but ignore the intersection (those that have existing 32-bit binaries and want those to run after 2038?), things could become noticeably easier. The price for that is a mid-2030s EOL time on any existing 32-bit glibc ports, any binaries linked to them, and any distros built upon that, and replacing them with something else that is binary incompatible but can coexist within e.g. a container. There are several options what such a replacement might look like, some that come to mind would include: - A patchset against glibc that replaces all the time32 interfaces with time64 ones and that is maintained outside of the glibc code base by whoever is interested in this working. - A set of glibc architecture ports that can coexist with the existing ports but have new target triples and/or soname. These could be implemented and merged one architecture at a time and share most of the code with the existing ports. - Leave glibc unchanged and require users/distros to migrate to musl or something else if they need the time64 support. Any of the above approaches (including the current plan of supporting time32 and time64 in a single glibc binary) can of coexist, but the more incompatible approaches get implemented, the more fragmentation of ABIs we get. Note that we have never had such a forced transition on x86, but there are several examples on other architectures: - arm oabi/gnueabi/gnueabihf - ppc64/ppc64le - mips o32/n32/64 The migration is not much fun for users to say the least, but it's quite possible that the alternative is even worse. Arnd