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 508B41F461 for ; Tue, 16 Jul 2019 14:52:30 +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=cHWz3y8N4VvbAvjCVpmx9ojcGF5e8jF vl53qm6KnzIEgwNQ/95dWnB38dQgEOxgm5/jAXM3ucOULFZBmoXx84ZmNUAumhqG 9PTIxt1UMsnDdLcV82aHSWbQxgNo63Qhh5A+m1zhNtJSkIP5+1+UXwMxpcU/bqjM 3tkmc985m3Xw= 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=uCgHIuc7uSeUQkR/DFXZTwdLxTg=; b=G/0+t RrWwM1P26NOLdm+xy+inS5hccXVE48G2DbH4ZlFeZpOLT7s1A/1vyBOLKD4bW2hi Bgu+W2BJ1K9PqLWkVclN/aF6T30kfujVS93TRDLqqpBQE9hqWnMZasrrRxbZIG1a 7qg1kuQ7DJJVVg+NAuyrWEaqf2oRHuaKw1iVd8= Received: (qmail 91370 invoked by alias); 16 Jul 2019 14:52:28 -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 91361 invoked by uid 89); 16 Jul 2019 14:52:27 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-out.m-online.net To: Florian Weimer cc: libc-alpha@sourceware.org, 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: <874l3mjgi6.fsf@oldenburg2.str.redhat.com> References: <20190712072103.D3DBC24003A@gemini.denx.de> <874l3mjgi6.fsf@oldenburg2.str.redhat.com> Comments: In-reply-to Florian Weimer message dated "Tue, 16 Jul 2019 14:44:33 +0200." Date: Tue, 16 Jul 2019 16:52:16 +0200 Message-Id: <20190716145216.1C7CE240085@gemini.denx.de> Dear Florian, In message <874l3mjgi6.fsf@oldenburg2.str.redhat.com> you wrote: > > One difficult trade-off is that for you, this is just one-time > enablement work, but the regular contributors will be stuck with the > code you add forever. Especially since it touches 64-bit architectures > as well. I am aware of this, and I'm willing to go all necessary procedures to get things right. If someone points out a problem, we can address it, and move on. But we haven't seen any progress for a long time... > For me personally, the whole project is quite baffling. I'm interested > in 32-bit changes only to support legacy binaries, and this is new work > targeting new binaries. Indeed it is easy for all the big distros who dropped (at least commercial) support for 32 bit systems years ago. But this is only a fraction of the systems that are affected, and it's not only x86. There is a zillion of 32 bit ARM, Power architecture and MIPS devices out there, with more of them being sold for many more years to come, and many of these are used in products a) with product lifetimes exceeding Y2038 and b) where being Y2038 clean is a critical feature. I think this is part of the problem - the big distros are not really interested in this work, they see it only as a nuisance to their business cases. I cannot stop myself from stating that such an approach is egotistic at best, if not ignorant, or both. > Particularly for i386, it *will* lead to ABI > fragmentation. We can add dual ABI support for glibc, but for the rest > of the system, distributions will have to pick a default (probably with > their build flags selection), and they will make different choices. > Some distributions will focus on backwards compatibility with legacy > binaries, but others want to keep the i386 architecture alive for many > more years. I really do not want to deal with the resulting confusion, > but it seems that I do not have any choice there. As mentioned, it is not only about i386. There are countless Embedded Systems running 32 bit ARM, PPC and MIPS systems. > 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. Thanks. 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 "Text processing has made it possible to right-justify any idea, even one which cannot be justified on any other grounds." -- J. Finnegan, USC.