From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.devel Subject: Re: Pure space Date: Sat, 17 Aug 2024 11:38:36 +0000 Message-ID: <87sev3idl0.fsf@protonmail.com> References: <87cym8jngk.fsf@protonmail.com> <864j7j65b1.fsf@gnu.org> <874j7jk06d.fsf@protonmail.com> <86bk1r2zj7.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5844"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Aug 17 14:40:37 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sfIjV-0001MT-C0 for ged-emacs-devel@m.gmane-mx.org; Sat, 17 Aug 2024 14:40:37 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sfIj4-0002pq-Cr; Sat, 17 Aug 2024 08:40:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sfHlg-0002kL-Ah for emacs-devel@gnu.org; Sat, 17 Aug 2024 07:38:48 -0400 Original-Received: from mail-40131.protonmail.ch ([185.70.40.131]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sfHld-0005Ey-KD; Sat, 17 Aug 2024 07:38:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1723894721; x=1724153921; bh=XsGwvUVKh1RnwsNBZullFS6zVGLRW2hEWQakb8/VUE0=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=WfdRogrIXOGkd0jX34Z8HNML9TbVLbDkqeyMzifQfvO2qKAzEVgkqtjpKWHPt1hkU uj0FHSdj/enijJxSqX0lkofFDro2FgWWVjcGIBF9cGisQIwJmN2jYtgbJ92rmTv/ZB v/vItLbsElyk5P6pOeiqF39rx58ZHQAgs63E3I2tCOizji4ltaZXiztx4eBNjxkHx/ jHiP4amwMi3pliqPAZoaisec8eJ8TeFe3Pg8Mcq0l/bf4P34U06XQBd5C1ZuIaDfRt IhbUfR0czYUNdMKNn942HsrlDDsrOLdU8B/k5CIoXhElnPvrNvb/NRp2LtZmTuAJOP 9JTop63CS7YjQ== In-Reply-To: <86bk1r2zj7.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 0029f1e7974979c2971f46959161a6db587236d0 Received-SPF: pass client-ip=185.70.40.131; envelope-from=pipcet@protonmail.com; helo=mail-40131.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sat, 17 Aug 2024 08:40:08 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:322842 Archived-At: "Eli Zaretskii" writes: >> Date: Sat, 17 Aug 2024 08:45:16 +0000 >> From: Pip Cet >> Cc: emacs-devel@gnu.org >> >> "Eli Zaretskii" writes: >> >> >> Date: Fri, 16 Aug 2024 19:07:42 +0000 >> >> From: Pip Cet >> >> >> >> can we revisit the question of whether we still want pure space? >> > >> > We already decided in the past to remove the pure space only when we >> > remove the support for unexec builds. >> >> IIRC, the situation was that unexec builds were broken on master at the >> point I proposed the pure space removal. I filed a bug about unexec and >> things were fixed some time later. >> >> Pure space and unexec aren't closely related at all, and the rebased >> scratch/no-purespace branch, after some tedious fixes, starts fine when >> configured with --with-dumping=3Dunexec. (Of course, those tedious fixes were completely unrelated to the dumping method used). > See my other messages in this thread. I asked whether the decision to keep purespace (by artificially linking it to another feature which we want to keep) could be revisited. I take it your answer is "no". IMO, circumstances have changed considerably. My guess is you disagree. If the two issues are to be considered inextricably linked (which, again, they're not; removing pure space does not require any changes to unexec dumping), then any effort to maintain the purespace code must count as "investing any development efforts in the unexec builds", because that's the only reason maintaining purespace is still necessary. IOW, if we count all the complexity and maintenance work that purespace requires as costs of keeping the unexec builds, then we should drop unexec ASAP. >> > So if we no longer want unexec >> > in Emacs 31 and beyond, we can remove pure space (and the unexec build >> > as well) on master. >> >> What do you think about making pure space overflow fatal as a first >> step? > > How would that help? It would mean we could do without changes such as those in the patch attached to the original message. Pip