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.

We're certainly going to remove ia64 from Debian Ports within the next two months.

* Same here, specifically who is "We"?

See above.

* 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'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. 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

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi all,

On 14.09.23 09:05, John Paul Adrian Glaubitz wrote:

Hi Mathieu!

On Thu, 2023-09-14 at 08:46 +0200, Mathieu Malaterre wrote:

Could someone please double check what I did at:

* https://buildd.debian.org/status/fetch.php?pkg=highway&arch=ia64&ver=1.0.7-4&stamp=1694591500&raw=0

For some reason LTO produces a FTBFS.

Some more details at:

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051772

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?

We're certainly going to remove ia64 from Debian Ports within the next two months.

* Same here, specifically who is "We"?

* 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"...

So I wouldn't bother.

Adrian

Cheers,
Frank

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Frank!

On Thu, 2023-09-14 at 12:15 +0200, Frank Scheiner wrote:

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.

ia64 is a VLIW architecture which puts a lot of the optimization burden onto the compiler [1]. At some point, this was considered to be of advantage but
it turned out to bring more problems than advantages which is why the approach was eventually abandoned.

e 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?

No, ultimately it's just my decision what happens to the Debian port. But there is
no point in maintaining the Debian port if the upstream projects removed support for
ia64.

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.

Well, this is already the case. There is no one really working on ia64 anymore. People
are sometimes fixing regressions here and there but that cannot be considered maintenance.

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.

Not really. As mentioned above, ia64 is special in its complexity and requires much more
work to make substantial changes to the kernel or the toolchain. Most architectures have
just one stack that is growing downwards, for example. ia64, on the other hand, has not
just one but two stacks that grow into opposite directions.

Also, as mentioned before, ia64 adds a lot of extra code to the compiler which no other
architecture does. The Ruby interpreter, for example, contained a lot of ia64-specific
code to deal with the special stack layout on this architecture. The code was removed
already because it posed a lot of maintenance burden [2]. There is no such code for all
the other architectures in Ruby.

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.

As explained above, ia64 is a very special architecture and it cannot be compared to other
architectures really. If you remember the security issue that Linus fixed back in July [3],
he explained that fixing the issue was straight-forward on most architectures while it was
rather difficult on ia64. And this is because of the complex design of the architecture.

This is most likely also the reason why QEMU never provided emulation support for ia64.

Adrian

[1] https://en.wikipedia.org/wiki/Very_long_instruction_word
[2] https://github.com/ruby/ruby/commit/d17344cfc56edc4599252041b3ec0d46af0851fd
[3] https://www.phoronix.com/news/Linux-65-User-Mode-Stack-Expand

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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-fc4b47325a7b@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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)