From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-relay-internal-1.canonical.com (smtp-relay-internal-1.canonical.com [185.125.188.123]) by sourceware.org (Postfix) with ESMTPS id E1D4C3858D3C for ; Wed, 1 Feb 2023 22:22:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E1D4C3858D3C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=canonical.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=canonical.com Received: from mail-pj1-f70.google.com (mail-pj1-f70.google.com [209.85.216.70]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id 1B35E41ADF for ; Wed, 1 Feb 2023 22:22:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1675290171; bh=dtpy8VWcTq2lKbGrfwllD13iw+ZAwbJMuQ0Mb6//KK4=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=d1qkDhUGxI7CatO3LO85lKHZsaAc//lHhcz6OctYzPCjkJ5Mduyv8S+kCsTtNWhb6 NogucV9SnSh23PE01msQFIrE60xI+7g66cghddNW52y5O2cuGvPlV/diyAWYq8Z/c1 IKDLOrQHA9MGENIWZ0D8vxCCuWRmAWImz5qCsoXmwAln99tzzimGW5ZktImH3FPHeX yg1i0x2BoJRQ5+TWDhi3etyQUSYMoJDwsQqinoOh1i0QaZWUEjcm4ZFJlZeTD2QVzk QkJBtB7YAJcPcUdq52WlorUX9Akp3h1QRYRZJdQE5XuNz974ErHMkNrX0K5Prb5oAi f7VAPmmWgORZQ== Received: by mail-pj1-f70.google.com with SMTP id ip10-20020a17090b314a00b002303f0e68b9so1102172pjb.6 for ; Wed, 01 Feb 2023 14:22:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dtpy8VWcTq2lKbGrfwllD13iw+ZAwbJMuQ0Mb6//KK4=; b=suz13Ty/QwVMbLvnWONHgpoYTmJbPD3W3SN06mk4wRJesyajREcNEM6iwbYT4MnuUc LKjAA84+n8ZN0UAPIMHnMFiaAhkXLuEIqMCyV767HVBYqwBVQGX2O9Cd4fdU8rgOXozh 7YqMrZxzYt6HLiYmmWOR9z6tzGa8rOmytYbwR7eug9VDOOSzfEUUILAXfsxOzowHJ/7s bZqHKgJD1mV8nMbRbzDd18C1tiIbIrrWRf9tkqTVhvwg4imJNphHEzz8F0CVOPPddMlS oWdoLEi/qGNsYDlsLFxBzwJ7aB1ehzm1jeTDQQ3nBXMXj8oeTU0iaYBESxaLYF/zdsNX 44ag== X-Gm-Message-State: AO0yUKVHgWy6yqLQeIsvWENsp7Czt+UfWSI+JPyurZswGropSgShAWw5 t7bhjFEX75P1LTxwUXJEolCiXJmp6dEPmDoUCsI/rdqCWNmbNCQY92o2uvjuylb04xrs1qLozz2 hdMXsVwPFkZla6b3fuH4O4ogaWv3qnIZ1VIvO4PZnES4S8t85s8AlfQ== X-Received: by 2002:a17:90a:ab8d:b0:22c:519f:c2cb with SMTP id n13-20020a17090aab8d00b0022c519fc2cbmr70484pjq.115.1675290168072; Wed, 01 Feb 2023 14:22:48 -0800 (PST) X-Google-Smtp-Source: AK7set/fKEMthLxsS2x9ApaT1J0MJ6Au95ZH4ckMTtOEeXp1x4GtkiBFZjSibAyji3vxQcBRkWDxcObrNLVAKjS3Qk4= X-Received: by 2002:a17:90a:ab8d:b0:22c:519f:c2cb with SMTP id n13-20020a17090aab8d00b0022c519fc2cbmr70480pjq.115.1675290167723; Wed, 01 Feb 2023 14:22:47 -0800 (PST) MIME-Version: 1.0 References: <10857996.18pcnM708K@pinacolada> <7196595.N7aMVyhfb1@pinacolada> <7271eb94-b5d7-69d6-9be0-ca1afda29a50@cs.ucla.edu> <2342ab66-6ac6-17d8-3693-8e2fd93fc8a1@linaro.org> <87bkmdwdv8.fsf@oldenburg.str.redhat.com> In-Reply-To: <87bkmdwdv8.fsf@oldenburg.str.redhat.com> From: Michael Hudson-Doyle Date: Thu, 2 Feb 2023 11:22:36 +1300 Message-ID: Subject: Re: time64 / Large File Support: 2) default time64 breaks legacy 32bit binaries To: Florian Weimer Cc: Sam James via Libc-alpha , Adhemerval Zanella Netto , Sam James Content-Type: multipart/alternative; boundary="00000000000057e80b05f3aae3d4" X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --00000000000057e80b05f3aae3d4 Content-Type: text/plain; charset="UTF-8" On Thu, 2 Feb 2023 at 05:27, Florian Weimer via Libc-alpha < libc-alpha@sourceware.org> wrote: > * Sam James via Libc-alpha: > > > Right, it seems RH has some needs due to supporting existing > > customers, but I don't think this should unduly affect what glibc > > upstream does if there's one clear technical path forward. Nobody > > seems to actually dispute that the end-game here is a hard switch at > > some point. Just about when. > > I'm mostly worried about the glibc project issuing a statement that > distributions should change the i386 ABI of libraries layered on top of > glibc. I don't quite see how this is in anyone's interest. > > What's the reason for a 32-bit x86 distribution at this point? Support > for old hardware which can't run 64-bit binaries? Running 32-bit > binaries which can't be rebuilt? Optimizing the footprint of workloads > that fit into a 32-bit address space? > The only reason Ubuntu still builds any packages on i386 at all is reason 2 here, to allow people to run old binaries that can't be rebuilt. As time passes the binaries that people care about are increasingly games. I presume for the cases where y2038 matters the default solution will be to run these binaries in a namespace that lies about the time. Only the first reason (old hardware on current distributions) can > justify the ABI bump. And it's in direct conflict with the second > reason. > Exactly. > For the third reason, it may be more approriate to revive the x32 port. > At least it doesn't interfere with legacy use. There's a non-upstream > ILP32 port for aarch64, too, so the largely the same choice is available > over there (although 32-bit-only CPUs that may run glibc code are still > being manufactured in the Arm ecosystem, so the tradeoffs are different > over there, I assume). > The 32-bit arm would is an entirely different calculation, yes. There are definitely devices being manufactured today that run Linux 32-bit that have the sort of expected lifetime that will bump into y2038 issues. I really hope the manufacturers have a plan! OTOH, there isn't a large pile of old armhf binaries lying around that people want to keep working in the same way there is on x86. For people who use yocto or buildroot they should just start passing -D_TIME_BITS=64 and rebuild the world but general purpose, package based distributions have a more delicate dance to perform (FWIW, we don't have a fully fledged plan for Ubuntu yet but we're certainly starting to think about it). > My hunch is that the most likely outcome of switching distributions to > 64-bit time_t is that the i386 port goes away more quickly than I would > expect otherwise because it makes the port rather useless for most > existing users (especially with those distributions that no longer > maintain a 32-bit-only kernel). Personally, that wouldn't be a bad > outcome at all for me. But I doubt that this is what people who push > for this change have in mind. > Is anyone proposing that glibc will lose the ability to have the 32-bit time_t ABI? As you note that would kill the Ubuntu i386 port entirely (at some point this will probably happen anyway, people can always play their games in VMs but still). Cheers, mwh --00000000000057e80b05f3aae3d4--