Re: Retiring ia64

Hi Adrian,

On 14.09.23 10:56, John Paul Adrian Glaubitz wrote:
> Hi Frank!
>
> On Thu, 2023-09-14 at 10:42 +0200, Frank Scheiner wrote:
>>> I don't think that LTO really works on ia64. The toolchain has been bitrotting on
>>> this architecture for a while now and it's slated to be dropped from the kernel
>>> for v6.7.
>>
>> That's certainly new news after returning from vacation, so a few
>> questions come to my mind:
>>
>> * When was this decided and who decided it?
>
> That was suggested by me in the thread that was started by Ard where we were discussing
> the future of the port which you were also participating in. See the message of Ard's
> pull request message [1]. My suggestion was to drop ia64 after the next LTS release of
> the kernel as a compromise for all parties involved.

Aha, up until now I considered that nothing more than a suggestion and
[1] is just from Monday and catches me by surprise, too.

It wasn't forwarded to the Debian list though it explicitly mentions
Debian/ia64 or to me though a post from me was explicitly mentioned in
one of the involved patches ([2]).

[2]:
https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/commit/?h=remove-ia64&id=cf8e8658100d4eae80ce9b21f7a81cb024dd5057

And please everybody excuse my ignorance here - I surely don't have the
whole picture - but from my more or less regular kernel testing on my
Integrities (cross-build and boot to login on every ia64 machine I have)
since May 2023 I didn't see a single problem affecting ia64 as a whole
that generated "real" work in that time frame. If somebody has a
different view, please enlighten me.

The recent build problem:
```
Making kernel...
time make -j24
LOCALVERSION="-0bb80ecc33a8fb5a682236443c1e740d5c917d1d-ia64" ARCH=ia64
CROSS_COMPILE=ia64-linux- all
Mon Sep 11 06:24:43 PM CEST 2023
[...]
   LD [M]  net/sunrpc/sunrpc.ko
ia64-linux-ld: drivers/acpi/acpi_processor.o: in function
`acpi_early_processor_osc':
/usr/src/linux-on-ramdisk/torvalds-linux/drivers/acpi/acpi_processor.c:596:
undefined reference to `acpi_proc_quirk_mwait_check'
ia64-linux-ld: drivers/acpi/processor_pdc.o: in function
`acpi_early_processor_set_pdc':
/usr/src/linux-on-ramdisk/torvalds-linux/drivers/acpi/processor_pdc.c:113:
undefined reference to `acpi_proc_quirk_mwait_check'
make[2]: *** [scripts/Makefile.vmlinux:36: vmlinux] Error 1
make[1]: *** [/usr/src/linux-on-ramdisk/torvalds-linux/Makefile:1165:
vmlinux] Error 2
make: *** [Makefile:234: __sub-make] Error 2

real	3m25.286s
user	69m26.895s
sys	6m37.619s
2
```

... also see [3], details on [4]) has a trivial fix and has in my eyes
nothing to do with ia64 but with the fact that introducing a function
call without providing an implementation for that function ([5]) creates
a problem.

[3]:
https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/commit/?h=remove-ia64&id=a0334bf78b95532cec54f56b53e8ae1bfe7e1ca1

[4]:
https://lore.kernel.org/lkml/[email protected]/T/

[5]:
https://github.com/torvalds/linux/commit/9bd0c413b90c6517b4a2fbedb74f50df3421b50c#diff-906354b6bfe9645f20a74307ab5744d761eeb9dedda28b08e75982b125e17c15R596

>>> We're certainly going to remove ia64 from Debian Ports within the next two months.
>>
>> * Same here, specifically who is "We"?
>
> See above.

Actually I wanted to know which people make the decisions for the Debian
port for ia64. So you and Ard then?

>> * And if that is already decided, why investing time in fixing ia64
>> problems in GRUB? Seems to be a perfect waste of time if "We"'re going
>> to remove it anyhow "within the next two months"...
>
> The idea was to have ia64 supported in the upcoming 6.6 LTS kernel so that users interested
> in the port will be able to use it for a foreseeable future in distributions such as Gentoo
> while the upstream developers of the kernel, toolchain and glibc will be able to remove it
> for future releases.
>
> Fixing ia64 support in GRUB is necessary to make sure that the 2.12 release will still properly
> work on the architecture. What happens with ia64 support after GRUB 2.12 has not been decided
> yet.

I figure nobody will ever touch it again, judging by the fact that no
other free OS (I mean the BSDs here) has managed to enable real support
for it.

I assume if this goes through like that, we will see a lot of "working"
arches (see your list below as example) being dropped from the Linux
kernel and the remaining ecosystem in the near future.

> I'm not a big fan of dropping architectures either, but the truth is that ia64 is rather complex
> from a software perspective and causes a lot of headache for upstream developers.

Well, I didn't see that in the timeframe vom May to now, but I only
looked at the kernel, see above.

And as everybody is telling me that (1) nobody uses the architecture
anymore and/or (2) the majority of developers don't have real machines
at hand and no emulation is available (except for Ski), I wonder how
much headaches this can create if at the same time most developers
cannot or just don't verify if there is a problem for ia64 originating
from their changes.

So how do they know their headaches come from ia64? I'd rather have some
hard data points about that.

> Combined with
> the fact that neither the kernel nor the toolchain nor glibc have any people maintaining the
> port.
>
> Again, this wasn't a lighthearted decision and I understand if some people disagree with this step,
> however we have to be considerate with the rest of the community and especially people maintaining
> these relevant upstream projects.
>
> As retro port maintainers, we still have many other great architectures such as Alpha, SPARC, PA-RISC
> and MC68000 to take care of and I think we should focus on these as not only do these have more users
> but also there are people still taking care of the upstream support in the kernel, toolchain and glibc
> in most cases.
>
> Adrian
>
>> [1] https://marc.info/?l=linux-arch&m=169446754424344&w=1

Cheers,
Frank

P.S.
I am unavailable for the remainder of the day, so don't mind a missing
reaction from me after this one.