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
