From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 7AE8B3858CDA for ; Wed, 1 Feb 2023 16:26:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7AE8B3858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675268819; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=3YUdkoRrf4Pv3o9jLMyBMOcVWZuvMsQj/LjgVPqevNE=; b=QhdQzLsNraPg7MDAiIWcCLI7sHKUrHeZoZGp6UZqYn68tgR74NlllonvkTEik/W7wuL4MF AAtjQTEU8/26Po7RSBzI4vzydwfBepZAofYsVhVX18+TDdqySHnJEn5wnjaJCgIyxngtCG 4BmpAvCE2Ov1JE0jIwJdYzDcEgmPTnA= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-442-32vXUV88OraJC-KugzM-nQ-1; Wed, 01 Feb 2023 11:26:54 -0500 X-MC-Unique: 32vXUV88OraJC-KugzM-nQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id CE54C88B7A6; Wed, 1 Feb 2023 16:26:53 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.194.58]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 273BFC15BAE; Wed, 1 Feb 2023 16:26:52 +0000 (UTC) From: Florian Weimer To: Sam James via Libc-alpha Cc: Adhemerval Zanella Netto , Sam James Subject: Re: time64 / Large File Support: 2) default time64 breaks legacy 32bit binaries References: <10857996.18pcnM708K@pinacolada> <7196595.N7aMVyhfb1@pinacolada> <7271eb94-b5d7-69d6-9be0-ca1afda29a50@cs.ucla.edu> <2342ab66-6ac6-17d8-3693-8e2fd93fc8a1@linaro.org> Date: Wed, 01 Feb 2023 17:26:51 +0100 In-Reply-To: (Sam James via Libc-alpha's message of "Thu, 26 Jan 2023 23:35:06 +0000") Message-ID: <87bkmdwdv8.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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: * 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? Only the first reason (old hardware on current distributions) can justify the ABI bump. And it's in direct conflict with the second reason. 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). 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. Thanks, Florian