[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 64-bit time_t transition for 32-bit archs: a proposal



Hi Steve,

On Tue, May 16, 2023 at 09:04:10PM -0700, Steve Langasek wrote:
> * … but NOT on i386.  Because i386 as an architecture is primarily of
>   interest for running legacy binaries which cannot be rebuilt against a new
>   ABI, changing the ABI on i386 would be counterproductive, as mentioned in
>   https://wiki.debian.org/ReleaseGoals/64bit-time.

I've been reading the discussion around i386 a bit and found the
direction it has taken a little unproductive. I hope we can agree that
there is no consensus on keeping or changing the time ABI for i386 while
there is quite some consensus for your plan on changing the time ABI for
all other 32bit architectures in roughly the way you brought forward.

While the i386 discussion seemed a little unproductive at times, I think
there is one major argument that I feel is missing here. If keeping the
32bit time ABI for i386, that effectively becomes a divergence from
every other architecture. i386 will be the one and only architecture to
be time32. As it happens, I have some experience with such divergence
from how bootstrapping interacted with other transitions such as PIE.
Maintaining this kind of divergence has a non-trivial cost. Over time it
becomes more and more difficult and less and less people are interested
in doing it. As such, I see the addition of this kind of divergence as a
way of killing i386.

Judging from the conversation, killing i386 quite obviously is desired
by some participants, but evidently not by all. How quickly we want to
kill it is not obvious to me. However, I think it is fair to say that
keeping time32 on i386 will kill it rather sooner than later. With
time32, we cannot reasonably extend i386 beyond forky as we'd be running
too close to the final deadline.

Some of you may have been aware of that Debian Reunion in Hamburg
recently. There was a BoF on how Debian should decide about non-trivial
matters and one result of that BoF was "maybe we should GR more often".
I think the decision of what to do with time32 is not a really important
one despite some people being very opinionated about it. How about
settling it using a GR anyway? We perceive GRs as painful and there is a
saying that if something is difficult, let's do it more often. How about
trying to do GRs more often with this decision? I think it is pretty
clear that neither answer is wrong. It's a choice that we have make and
then to stick to. And we can learn something about whether GRs really
are painful. I think the worst of outcomes we could get here is going
into much further detail in a GR and adding lots of competing proposals
there. If that were to happen, I'd consider the experiment as failed.
Leaving the details to those who put up with the work (and that quite
obviously is Steve et al here) is important in my book. So unless we can
do it as simple as "i386 should keep being time32" vs "i386 should
become time64 by default", we probably shouldn't GR it.

Helmut


Reply to: