Re: Pure space

[Pip Cet <pipcet@protonmail.com>]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> Date: Sat, 17 Aug 2024 08:45:16 +0000
>> From: Pip Cet <pipcet@protonmail.com>
>> Cc: emacs-devel@gnu.org
>>
>> "Eli Zaretskii" <eliz@gnu.org> writes:
>>
>> >> Date: Fri, 16 Aug 2024 19:07:42 +0000
>> >> From: Pip Cet <pipcet@protonmail.com>
>> >>
>> >> 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=unexec.

(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