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/4bf71d86-d8a9-dce8-6a14-fc4b47325...@roeck-us.net/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.
