On Wed, 05 Jul 2023 at 17:22:14 +0100, Wookey wrote:
> On 2023-06-06 11:45 +0100, Simon McVittie wrote:
> > 1. i386 as a fully-featured architecture that you can run independently
> > on 32-bit x86 systems from roughly the 2000-2010 era
> >
> > 2. i386 as a multiarch foreign architecture to run legacy binaries on
> > modern x86_64 systems
>
> It is possible to have both these things, by treating this transtion
> as a new-ABI (i.e new architecture) transition, not a within-arch ABI
> transition.
>
> i.e we could keep the existing i386 for the gamers and have i386t64
> (or whatever we call it) for ongoing use of i386 as a real OS.
On Fri, 09 Jun 2023 at 16:39:38 +0000, Thorsten Glaser wrote:
> Ideally we’d keep the old i386 around for legacy binary-only libraries
> and executables and add an i586 architecture with a differing dynamic
> linker path
These are essentially the same suggestion, and if there are enough
developers interested in the use-case that I labelled (1.) above, then
I agree that i386t64 (or i586t64 or ia32 or whatever its newly-formed
porting team wants to call it) would be the way to achieve that.
Because legacy binaries already "know" that the backwards-compatible
architecture is labelled i386 and i?86-linux-gnu with its dynamic linker
at /lib/ld-linux.so.2, and by definition legacy binaries don't have
the opportunity to to change their assumptions, I think the new time64
architecture would need to have a new dpkg architecture name, multiarch
tuple, GNU tuple (i?86-linux-gnut64?) and canonical ELF linker path.
If the new architecture is fully co-installable and distinguishable via
ELF flags (like the way amd64, i386 and x32 are), then the procedure to
switch to it could be similar to switching from i386 to amd64, or armhf to
arm64: either reinstall, or add it as a foreign architecture and gradually
"crossgrade" core system packages to it. If it isn't distinguishable by
ELF flags (so the dynamic linker would attempt to load i386t64 libraries
into an i386 process or vice versa, and sometimes crash as a result)
then a reinstall would be required.
I am personally only interested in i386 for the use-case that I labelled
(2.) above, but I don't want to prevent anyone else from working on (1.).
(It's perhaps also worth noting that it's possible to upgrade from
i386 to amd64 without a net increase in e-waste by switching from i386
hardware to older amd64 hardware that has already been discarded by its
original owner: I'm typing this into a second-hand ex-corporate Lenovo
T480s, built in 2018 according to its serial number label, and the X220
that was previously very popular with DDs was a UEFI-capable amd64 from
around 2012.)
smcv
