(cross posted to several ia64 related mailing list)

Hello all,

As the maintainer of the EFI subsystem in Linux, I am one of the
people that have to deal with the impact that code refactoring for
current platforms has on legacy use of such code, in this particular
case, the use of shared EFI code in the Itanium Linux port.

I am sending this message to gauge the remaining interest in ia64
support across the OS/distro landscape, and whether people feel that
the effort required to keep it alive is worth it or not.

As a maintainer, I feel uncomfortable asking contributors to build
test their changes for Itanium, and boot testing is infeasible for
most, even if some people are volunteering access to infrastructure
for this purpose. In general, hacking on kernels or bootloaders (which
is where the EFI pieces live) is tricky using remote access.

The bottom line is that, while I know of at least 2 people (on cc)
that test stuff on itanium, and package software for it, I don't think
there are any actual users remaining, and so it is doubtful whether it
is justified to ask people to spend time and effort on this.

And for GRUB in particular (which is what triggered this message), it
is unclear to me why any machines still running would not be better
served by sticking with their current bootloader build, rather than
upgrading to a new build with a refactored EFI layer where the best
case scenario is that it boots the kernel in exactly the same way,
while there is a substantial risk of regressions.

For the Linux kernel itself, the situation is quite similar. There is
a non-zero effort involved in keeping things working, and if anyone
still needs to run their programs on Itanium, it is not clear to me
why that would require a recent version of the OS.

So bottom line: I am proposing we drop support for Itanium across the
board. Would anyone have any problems with that?

Kind regards,
Ard.

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

On Fri, 12 May 2023 at 20:50, Jesse Dougherty <Jesse@cypress-tech.com> wrote:

I'm a little bias because my company is a re-sellers of the HP Itanium
ia64 hardware (RX & ZX boxes), as well as PA-RISC. For that reason, I
would hate to see it fade away in any sector. The ia64 platform is still widely used with HP-UX Unix and Open VMS users worldwide. This hardware
is embedded in most every data center and large and medium companies
that have been around since the 80s/90s, its probably the oldest box
they have in there but its the one thats in the corner running for 20
years, long before most people started working there. PA-RICS is also massively intertwined into the US military as well as foreign
military's, they did that in the early 2000's and they are stuck with it..

I could go on but me as a hardware guy, I'm on team ia64 :-)

Thanks for the data point. Gwtting your angle as someone who supports
actual users is rather useful.

So how many of your customers would be adversely impacted by the lack
of an upgrade path to, say, Linux kernels beyond v6.3 or GRUB versions
beyond today's 2.06?

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

Dear Ard, all,

First of all, I demand nothing of other people in this regard, you
included. Please notice there's no "but" attached.

I think I have a little first-hand knowledge about how much effort is
involved in keeping an interesting architecture from the past running,
to the least since when I thought it would be a cool idea to maintain
the retired sgi port of OpenBSD...

I have a few remarks below...

On 12.05.23 17:57, Ard Biesheuvel wrote:

(cross posted to several ia64 related mailing list)

Hello all,

As the maintainer of the EFI subsystem in Linux, I am one of the
people that have to deal with the impact that code refactoring for
current platforms has on legacy use of such code, in this particular
case, the use of shared EFI code in the Itanium Linux port.

I am sending this message to gauge the remaining interest in ia64
support across the OS/distro landscape, and whether people feel that
the effort required to keep it alive is worth it or not.

As a maintainer, I feel uncomfortable asking contributors to build
test their changes for Itanium, and boot testing is infeasible for
most, even if some people are volunteering access to infrastructure
for this purpose. In general, hacking on kernels or bootloaders (which
is where the EFI pieces live) is tricky using remote access.

That is all doable, at least all HP Integrity gear I am familiar with -
and which surely make up the majority of ia64 machines in hobbyist use -
are equipped with full remote control (console, reset, power, etc.). The
main problem at least in Germany is the insanity of our energy prices,
which were already too high before they skyrocketed in the recent past.
But you also wrote:

The bottom line is that, while I know of at least 2 people (on cc)
that test stuff on itanium, and package software for it, I don't think
there are any actual users remaining, and so it is doubtful whether it
is justified to ask people to spend time and effort on this.

While I get your argument, I also find it important to be able to
innovate without destroying the past. And with the already severly
limited choice of current architectures for the masses (x86, arm), it
becomes even more important to keep what we have or had in the past, to
not end in a "If all you have is a hammer, everything looks like a
nail." type of future.

And for GRUB in particular (which is what triggered this message), it
is unclear to me why any machines still running would not be better
served by sticking with their current bootloader build, rather than
upgrading to a new build with a refactored EFI layer where the best
case scenario is that it boots the kernel in exactly the same way,
while there is a substantial risk of regressions.

Sure, and every ia64 machine I have still network boots fine with elilo,
even the rx2800-i2. Though most people still have their root FS on disk,
where elilo might limit the choice of the bootstrap file system(s).

Plus elilo is gone from the Debian repositories, just like yaboot,
leaving grub2 as the only bootloader for ia64 there at the moment - if
I'm not mistaken. And I assume Adrian invested quite some time and work
to get grub2 usable as default boot loader for ia64 in Debian.

But apart from this - also from other posts - it is pretty obvious that
you seem to be absolutely determined to remove ia64 support from the
Linux ecosystem. So removing it from the bootloader is just a step stone
to removing ia64 support from the Linux kernel and a discussion about
the bootloader seems futile then.

For the Linux kernel itself, the situation is quite similar. There is
a non-zero effort involved in keeping things working, and if anyone
still needs to run their programs on Itanium, it is not clear to me
why that would require a recent version of the OS.

So bottom line: I am proposing we drop support for Itanium across the
board. Would anyone have any problems with that?

Of course I would have a problem with that. AFAIK GNU/Linux is the last
free OS for these machines. And I don't see those machines as museum
pieces yet, but as options for interested people, coming back to the
hammer and nail thing from above.

But I demand nothing of you. And to be honest I can't contribute at this
level to ia64, as I just don't have the required expertise for this type
of hacking.

Apart from that I'd like to thank all people involved in keeping those interesting systems afloat for the good times I had and have on ia64 and
other interesting architectures and machines.

Cheers,
Frank

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

* Frank Scheiner:

On 12.05.23 17:57, Ard Biesheuvel wrote:

The bottom line is that, while I know of at least 2 people (on cc)
that test stuff on itanium, and package software for it, I don't think
there are any actual users remaining, and so it is doubtful whether it
is justified to ask people to spend time and effort on this.

While I get your argument, I also find it important to be able to
innovate without destroying the past. And with the already severly
limited choice of current architectures for the masses (x86, arm), it
becomes even more important to keep what we have or had in the past, to
not end in a "If all you have is a hammer, everything looks like a
nail." type of future.

The history doesn't go away. We still have pre-built ia64 system
images, the sources, and current machines can run ia64 code under
QEMU. Those host systems will remain available (maybe under
virtualization) for many, many years to come. So if anyone wants to
experiment with an architecture that has register trap bits and things
like that, it's possible.

I expect the rest of the hardware itself is not remarkable, and
anything useful has been thoroughly reused for other systems (like we
did for the Itanium C++ ABI on the software side).

From the userspace side, the issue is not so much testing (if we

bother to test our changes at all, we can use emulation), but
half-completed implementaton work (I ran into missing relaxations in
the link editor a while back, for example), and those limitations have
knock-on effects on generic code that we have to maintain.

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

On Wed, 17 May 2023 at 20:39, Frank Scheiner <frank.scheiner@web.de> wrote:

Dear Ard, all,

First of all, I demand nothing of other people in this regard, you
included. Please notice there's no "but" attached.

I think I have a little first-hand knowledge about how much effort is involved in keeping an interesting architecture from the past running,
to the least since when I thought it would be a cool idea to maintain
the retired sgi port of OpenBSD...

Hello Frank,

Thanks for sharing your insights.

I have a few remarks below...

On 12.05.23 17:57, Ard Biesheuvel wrote:

(cross posted to several ia64 related mailing list)

Hello all,

As the maintainer of the EFI subsystem in Linux, I am one of the
people that have to deal with the impact that code refactoring for
current platforms has on legacy use of such code, in this particular
case, the use of shared EFI code in the Itanium Linux port.

I am sending this message to gauge the remaining interest in ia64
support across the OS/distro landscape, and whether people feel that
the effort required to keep it alive is worth it or not.

As a maintainer, I feel uncomfortable asking contributors to build
test their changes for Itanium, and boot testing is infeasible for
most, even if some people are volunteering access to infrastructure
for this purpose. In general, hacking on kernels or bootloaders (which
is where the EFI pieces live) is tricky using remote access.

That is all doable, at least all HP Integrity gear I am familiar with -
and which surely make up the majority of ia64 machines in hobbyist use -
are equipped with full remote control (console, reset, power, etc.). The
main problem at least in Germany is the insanity of our energy prices,
which were already too high before they skyrocketed in the recent past.

This is good to know.

But you also wrote:

The bottom line is that, while I know of at least 2 people (on cc)
that test stuff on itanium, and package software for it, I don't think there are any actual users remaining, and so it is doubtful whether it
is justified to ask people to spend time and effort on this.

While I get your argument, I also find it important to be able to
innovate without destroying the past. And with the already severly
limited choice of current architectures for the masses (x86, arm), it
becomes even more important to keep what we have or had in the past, to
not end in a "If all you have is a hammer, everything looks like a
nail." type of future.

I don't disagree with that. But why does this imply that Linux should
be kept alive on an architecture that is not used by anyone to run
Linux in the first place? Could you be more specific about how you see
this correlation?

And for GRUB in particular (which is what triggered this message), it
is unclear to me why any machines still running would not be better
served by sticking with their current bootloader build, rather than upgrading to a new build with a refactored EFI layer where the best
case scenario is that it boots the kernel in exactly the same way,
while there is a substantial risk of regressions.

Sure, and every ia64 machine I have still network boots fine with elilo,
even the rx2800-i2. Though most people still have their root FS on disk, where elilo might limit the choice of the bootstrap file system(s).

So which Linux versions are you running on these machines? And what
are you using them for (if you don't mind me asking)?

Plus elilo is gone from the Debian repositories, just like yaboot,
leaving grub2 as the only bootloader for ia64 there at the moment - if
I'm not mistaken. And I assume Adrian invested quite some time and work
to get grub2 usable as default boot loader for ia64 in Debian.

Sure. But I am not suggesting retroactively removing ia64 support from
GRUB. As I explained, both the firmware interfaces and the Linux boot
protocol are essentially set in stone at this point, so upgrading to a
newer GRUB has no upsides.

But apart from this - also from other posts - it is pretty obvious that
you seem to be absolutely determined to remove ia64 support from the
Linux ecosystem. So removing it from the bootloader is just a step stone
to removing ia64 support from the Linux kernel and a discussion about
the bootloader seems futile then.

Not at all. As a Linux subsystem maintainer, I have to keep the bigger
EFI picture in mind when I accept contributions from people who may
work on many different topics and projects, and move on to something
else immediately. So generally, the responsibility of balancing the
interests of different EFI stakeholders falls to me, and I have to
decide how much emphasis to put on build and boot testing across
architectures and use cases, for instance. So what purpose is being
served by either them or me spending a disproportionate amount of time
build and boot testing code that nobody is ever going to run?

Up to this point, not a single person has indicated that Linux on ia64
is important for an actual use case. The only responses I am getting
(which are much appreciated, don't get me wrong) generally state that
ongoing ia64 support is important for the common good, but nobody
actually uses Linux/ia64 for anything other than checking whether it
still works, and churning out distro packages that nobody ever
downloads.

For the Linux kernel itself, the situation is quite similar. There is
a non-zero effort involved in keeping things working, and if anyone
still needs to run their programs on Itanium, it is not clear to me
why that would require a recent version of the OS.

So bottom line: I am proposing we drop support for Itanium across the board. Would anyone have any problems with that?

Of course I would have a problem with that. AFAIK GNU/Linux is the last
free OS for these machines. And I don't see those machines as museum
pieces yet, but as options for interested people, coming back to the
hammer and nail thing from above.

By 'interested people' you mean other people than yourself, right?

But I demand nothing of you. And to be honest I can't contribute at this level to ia64, as I just don't have the required expertise for this type
of hacking.

Apart from that I'd like to thank all people involved in keeping those interesting systems afloat for the good times I had and have on ia64 and other interesting architectures and machines.

Again, your insight is much appreciated, even if we fundamentally disagree.

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

RGVhciBtYXRvcm8sIEZsb3JpYW4sDQoNCk9uIDE3LjA1LjIzIDIzOjQ3LCBtYXRvcm8gd3Jv dGU6DQo+IE9uIDIwMjMtMDUtMTcgMTU6MzksIEZsb3JpYW4gV2VpbWVyIHdyb3RlOg0KPj4g KiBGcmFuayBTY2hlaW5lcjoNCj4+DQo+Pj4gT24gMTIuMDUuMjMgMTc6NTcsIEFyZCBCaWVz aGV1dmVsIHdyb3RlOg0KPj4+PiBUaGUgYm90dG9tIGxpbmUgaXMgdGhhdCwgd2hpbGUgSSBr bm93IG9mIGF0IGxlYXN0IDIgcGVvcGxlIChvbiBjYykNCj4+Pj4gdGhhdCB0ZXN0IHN0dWZm IG9uIGl0YW5pdW0sIGFuZCBwYWNrYWdlIHNvZnR3YXJlIGZvciBpdCwgSSBkb24ndCB0aGlu aw0KPj4+PiB0aGVyZSBhcmUgYW55IGFjdHVhbCB1c2VycyByZW1haW5pbmcsIGFuZCBzbyBp dCBpcyBkb3VidGZ1bCB3aGV0aGVyIGl0DQo+Pj4+IGlzIGp1c3RpZmllZCB0byBhc2sgcGVv cGxlIHRvIHNwZW5kIHRpbWUgYW5kIGVmZm9ydCBvbiB0aGlzLg0KPj4+DQo+Pj4gV2hpbGUg SSBnZXQgeW91ciBhcmd1bWVudCwgSSBhbHNvIGZpbmQgaXQgaW1wb3J0YW50IHRvIGJlIGFi bGUgdG8NCj4+PiBpbm5vdmF0ZSB3aXRob3V0IGRlc3Ryb3lpbmcgdGhlIHBhc3QuIEFuZCB3 aXRoIHRoZSBhbHJlYWR5IHNldmVybHkNCj4+PiBsaW1pdGVkIGNob2ljZSBvZiBjdXJyZW50 IGFyY2hpdGVjdHVyZXMgZm9yIHRoZSBtYXNzZXMgKHg4NiwgYXJtKSwgaXQNCj4+PiBiZWNv bWVzIGV2ZW4gbW9yZSBpbXBvcnRhbnQgdG8ga2VlcCB3aGF0IHdlIGhhdmUgb3IgaGFkIGlu IHRoZSBwYXN0LCB0bw0KPj4+IG5vdCBlbmQgaW4gYSAiSWYgYWxsIHlvdSBoYXZlIGlzIGEg aGFtbWVyLCBldmVyeXRoaW5nIGxvb2tzIGxpa2UgYQ0KPj4+IG5haWwuIiB0eXBlIG9mIGZ1 dHVyZS4NCj4+DQo+PiBUaGUgaGlzdG9yeSBkb2Vzbid0IGdvIGF3YXkuwqAgV2Ugc3RpbGwg aGF2ZSBwcmUtYnVpbHQgaWE2NCBzeXN0ZW0NCj4+IGltYWdlcywgdGhlIHNvdXJjZXMsIGFu ZCBjdXJyZW50IG1hY2hpbmVzIGNhbiBydW4gaWE2NCBjb2RlIHVuZGVyDQo+PiBRRU1VLsKg IFRob3NlIGhvc3Qgc3lzdGVtcyB3aWxsIHJlbWFpbiBhdmFpbGFibGUgKG1heWJlIHVuZGVy DQo+PiB2aXJ0dWFsaXphdGlvbikgZm9yIG1hbnksIG1hbnkgeWVhcnMgdG8gY29tZS7CoCBT byBpZiBhbnlvbmUgd2FudHMgdG8NCj4+IGV4cGVyaW1lbnQgd2l0aCBhbiBhcmNoaXRlY3R1 cmUgdGhhdCBoYXMgcmVnaXN0ZXIgdHJhcCBiaXRzIGFuZCB0aGluZ3MNCj4+IGxpa2UgdGhh dCwgaXQncyBwb3NzaWJsZS4NCj4+DQo+PiBJIGV4cGVjdCB0aGUgcmVzdCBvZiB0aGUgaGFy ZHdhcmUgaXRzZWxmIGlzIG5vdCByZW1hcmthYmxlLCBhbmQNCj4+IGFueXRoaW5nIHVzZWZ1 bCBoYXMgYmVlbiB0aG9yb3VnaGx5IHJldXNlZCBmb3Igb3RoZXIgc3lzdGVtcyAobGlrZSB3 ZQ0KPj4gZGlkIGZvciB0aGUgSXRhbml1bSBDKysgQUJJIG9uIHRoZSBzb2Z0d2FyZSBzaWRl KS4NCj4+DQo+PiBGcm9tIHRoZSB1c2Vyc3BhY2Ugc2lkZSwgdGhlIGlzc3VlIGlzIG5vdCBz byBtdWNoIHRlc3RpbmcgKGlmIHdlDQo+PiBib3RoZXIgdG8gdGVzdCBvdXIgY2hhbmdlcyBh dCBhbGwsIHdlIGNhbiB1c2UgZW11bGF0aW9uKSwgYnV0DQo+PiBoYWxmLWNvbXBsZXRlZCBp bXBsZW1lbnRhdG9uIHdvcmsgKEkgcmFuIGludG8gbWlzc2luZyByZWxheGF0aW9ucyBpbg0K Pj4gdGhlIGxpbmsgZWRpdG9yIGEgd2hpbGUgYmFjaywgZm9yIGV4YW1wbGUpLCBhbmQgdGhv c2UgbGltaXRhdGlvbnMgaGF2ZQ0KPj4ga25vY2stb24gZWZmZWN0cyBvbiBnZW5lcmljIGNv ZGUgdGhhdCB3ZSBoYXZlIHRvIG1haW50YWluLg0KPiANCj4gRllJLCBRRU1VIGRvZXMgbm90 IGhhdmUgaWE2NCBob3N0IG9yIHRhcmdldCBzdXBwb3J0LCBub3QgZXZlbiBUQ0cuDQoNCkkg YXNzdW1lIEZsb3JpYW4gbWVhbnMgdXNlciBtb2RlIGVtdWxhdGlvbiwgd2hpY2ggZm9yIGV4 YW1wbGUgY2FuIGJlIA0KdXNlZCB0byBjb21wbGV0ZSBhIGBkZWJvb3RzdHJhcCAtLWZvcmVp Z24gWy4uLl1gIHJ1biB3aGVuIHlvdSBkb24ndCBoYXZlIA0KYW4gZXhpc3RpbmcgaWE2NCB1 c2VybGFuZCBvbiByZWFsIGhhcmR3YXJlIGF0IGhhbmQuDQoNCkkgZG91YnQgdGhhdCBpdCB3 b3JrcyBpbiB0aGUgZXhhY3Qgc2FtZSB3YXkgdGhhbiB0aGUgcmVhbCB0aGluZywgdGhvdWdo LiANClN1Y2ggZGlmZmVyZW5jZXMgYXJlIHBhcnQgb2YgdGhlIHJlYXNvbnMgd2h5IHRoZSBP cGVuQlNEIGRldnMgZG9uJ3Qgc2VlbSANCnRvIHVzZSBjcm9zcyBjb21waWxlcnMgb3Igdmly dHVhbGl6ZWQgb3IgZW11bGF0ZWQgc3lzdGVtcyB0byBwcm9kdWNlIGFuZCANCnRlc3QgdGhl aXIgT1MsIHRob3VnaCB0aGV5IHNlZW0gdG8gdXNlIGNyb3NzIGNvbXBpbGVycyBmb3IgdGhl IGJyaW5ndXAgDQpvZiBuZXcgcGxhdGZvcm1zIElJQy4NCg0KQnV0IGlmIGl0J3MgZ29vZCBl bm91Z2ggdG8gcnVuIGlhNjQgYmluYXJpZXMgb24gb3RoZXIgYXJjaGVzLCB3aHkgbm90Lg0K DQpIYXZlIGEgbmljZSB3ZWVrZW5kLA0KRnJhbmsNCg0K

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

Dear Ard, all,

@new CC addressees:

The thread starts here (for example on marc.info, though it's slow to
respond currently, at least for me):

https://marc.info/?l=linux-ia64&m=168390699019217&w=2

I also recommend to read through the following threads and article to
get the background:

* https://marc.info/?l=linux-ia64&m=167490894109449&w=2
* https://marc.info/?l=linux-ia64&m=167645523010657&w=2
* https://www.theregister.com/2023/02/16/itanium_linux_kernel/
* https://marc.info/?l=grub-devel&m=168380680728904&w=2

On 17.05.23 23:41, Ard Biesheuvel wrote:

On Wed, 17 May 2023 at 20:39, Frank Scheiner <frank.scheiner@web.de> wrote:

On 12.05.23 17:57, Ard Biesheuvel wrote:

The bottom line is that, while I know of at least 2 people (on cc)
that test stuff on itanium, and package software for it, I don't think
there are any actual users remaining, and so it is doubtful whether it
is justified to ask people to spend time and effort on this.

While I get your argument, I also find it important to be able to
innovate without destroying the past. And with the already severly
limited choice of current architectures for the masses (x86, arm), it
becomes even more important to keep what we have or had in the past, to
not end in a "If all you have is a hammer, everything looks like a
nail." type of future.

I don't disagree with that. But why does this imply that Linux should
be kept alive on an architecture that is not used by anyone to run
Linux in the first place? Could you be more specific about how you see
this correlation?

I don't think the main problem for ia64 is interest, I think it's
availability. These machines are rare - already because they weren't
sold in high numbers - and are usually quite expensive to acquire,
except if you can get them from the trasher, get them donated or cheap
by sheer luck.

Apart from that I also don't expect ordinary users to actually subscribe to:

* distributions@lists.freedesktop.org
* debian-ia64@lists.debian.org
* linux-ia64@vger.kernel.org
* port-ia64@netbsd.org

I assume even less would feel entitled to write to a thread like this one.

I therefore thought it would be a good idea to spam a few people in
addition. Hope you don't mind.

And for GRUB in particular (which is what triggered this message), it
is unclear to me why any machines still running would not be better
served by sticking with their current bootloader build, rather than
upgrading to a new build with a refactored EFI layer where the best
case scenario is that it boots the kernel in exactly the same way,
while there is a substantial risk of regressions.

Sure, and every ia64 machine I have still network boots fine with elilo,
even the rx2800-i2. Though most people still have their root FS on disk,
where elilo might limit the choice of the bootstrap file system(s).

So which Linux versions are you running on these machines? And what
are you using them for (if you don't mind me asking)?

I have a lot of machines of different vintage, a little from everything
and my ia64 machines only make a few of them. And I'm definitely the
bottleneck for work done on them.

But according to my notes I originally started with Debian Wheezy (so
3.2.x) on my rx2620 (w/2 x Montecito) and later (in 2017) on my rx4640
(w/4 x Madison) and rx2660 (w/1 x Montvale, later 2 x Montecito). I
tried to get configurations with different processor generations and
chipsets (e.g. zx1 with Madison/Montecito or zx2 with Montecito/Montvale
or Tukwila w/integrated memory controller) in order to be able to debug
cases that only affect specific combinations and there were some in the
recent past. Also in 2017 but later the year I had a brief episode of
Gentoo, as Gentoo had a newer Linux kernel (4.9.34) available on their installer ISO that worked on the rx2660. It took days to fix and
finalize a Gentoo installation for this machine but in the end I could
finally create "modern" Linux kernels on ia64. The shipped elilo didn't
work for on-disk installations though, as I later found out, so I
switched to the version from Debian Wheezy. It took nearly a year (until
June 2018) before I did revisit my ia64 machines, because work happened
on powerpc, ppc64, sparc64, sgi, hppa and others in between. The ia64
port of Debian Sid got a kernel package back then, most likely by Adrian
and others, and I wanted to switch my ia64 machines from Wheezy to Sid.
I needed to move on to Linux 3.14.x from Wheezy Backports to be able to debootstrap Sid back then and had to "fix" (I just reinstated a patch
that was dropped, see [1]) the klibc utils for the initramfs so they
worked and didn't segfault. Sadly the 4.17.0-rc7 didn't work (due to
"corrupted stack end detected inside scheduler"), but I could get the
rx4640 and rx2660 to work with the Gentoo kernel (4.9.95) instead, so
could actually run Debian Sid on them, though with a "non-native"
kernel. Sometime later I could procure a rx2800-i2 (w/1 x Tukwila) and
tried to put that to use. Gentoo's 4.14.x and the older 4.9.x were the
only Linux kernels that did work on this machine, though. Debian kernels started to work on the other machines with 4.17.14 in August 2018.
Between 2019 and 2022 not much did happen with these machines, because
of other interests. This started to change in 2022 and I am getting back
to it.

There is an issue since a while (see [2]) which does not affect the
rx2800-i2 (neither with (I checked that on Tuesday) nor w/o initramfs
(as pointed out on [3]). But all the other machines I have (all the
above, plus second rx2660 (w/1 x single-core Montvale) and rx6600 (w/4 x Montvale) are affected, so Linux on ia64 is not completely broken at the moment.

[1]: https://salsa.debian.org/kernel-team/klibc/-/merge_requests/1/diffs#9c96da0e9f91d7d8937b69b524702c106258f0d1

[2]: https://marc.info/?l=linux-ia64&m=167404713006203&w=2

[3]: https://marc.info/?l=linux-ia64&m=167710457217507&w=2

So in short: I ran and run every Linux kernel version I could get to
work on these, preferrably w/o building them myself. And I use(d) them
with the goal to make it easier for other people to use them (I can
detail that if needed), to assist other people in debugging specific
issues, to find out if a problem affects specific configurations only or
not and to test specific software pieces (e.g. grub for ia64 in Debian,
or the installer ISOs although I prefer network booting).

Considering that and also the work and effort put into Debian by Jason (Duerstock, +CC), Adrian and Jessica (Clarke, +CC) to get the ia64 port
of Sid going, plus the effort by Jessica and Sergei (Trofimovich, +CC, I
also put ia64@gentoo.org in CC now) and others for sure that was put
into fixing bugs (not only in the Linux kernel IIC) and testing by users
I dare to say that the work or pain (see e.g. Linus' take on that [4])
is shared between many people.

[4]: https://marc.info/?l=linux-ia64&m=167649168302428&w=2

And considering how bad the situation was for ia64 before it was
reestablished in Debian, I'd say the support for ia64 is in a much
better shape now than back then, thanks to all people involved.

Plus elilo is gone from the Debian repositories, just like yaboot,
leaving grub2 as the only bootloader for ia64 there at the moment - if
I'm not mistaken. And I assume Adrian invested quite some time and work
to get grub2 usable as default boot loader for ia64 in Debian.

Sure. But I am not suggesting retroactively removing ia64 support from
GRUB. As I explained, both the firmware interfaces and the Linux boot protocol are essentially set in stone at this point, so upgrading to a
newer GRUB has no upsides.

Sure. The question is, can it be handled downstream, e.g. can Debian
stay on grub2 - before your refactoring - for ia64 only? But as said,
elilo still works fine, though there seem to be specific versions that
don't as I just re-read in some older posts when going through the
debian-ia64 mailing list archive.

But again, I'm not afraid of loosing ia64 support in grub, but of
loosing it in the Linux kernel.

But apart from this - also from other posts - it is pretty obvious that
you seem to be absolutely determined to remove ia64 support from the
Linux ecosystem. So removing it from the bootloader is just a step stone
to removing ia64 support from the Linux kernel and a discussion about
the bootloader seems futile then.

Not at all.

So why then put effort in patches that remove ia64 from grub and Linux,
if the decision for pulling the plug on ia64 would be made by potential
users you claim there aren't any?

As a Linux subsystem maintainer, I have to keep the bigger
EFI picture in mind when I accept contributions from people who may
work on many different topics and projects, and move on to something
else immediately. So generally, the responsibility of balancing the
interests of different EFI stakeholders falls to me, and I have to
decide how much emphasis to put on build and boot testing across architectures and use cases, for instance. So what purpose is being
served by either them or me spending a disproportionate amount of time
build and boot testing code that nobody is ever going to run?

Up to this point, not a single person has indicated that Linux on ia64
is important for an actual use case.

What is an actual use case for you? Maybe it would be easier to know
what you consider legit.

How could support for RISC-V materialize in the Linux kernel under such circumstances, w/o users, w/o use cases and w/o hardware?

Is CI testing the Grid Community Toolkit on this arch to confirm its multiplatform interoperability a use case for you? What about examining
network performance with GridFTP and different NICs? What about
examining performance variations between different kernel versions and processor generations? I am sure users can think of many things they
could do on these machines, if they only had one at their hands.

Again, maybe it would be easier to know what you want to hear.

The only responses I am getting
(which are much appreciated, don't get me wrong) generally state that
ongoing ia64 support is important for the common good, but nobody
actually uses Linux/ia64 for anything other than checking whether it
still works, and churning out distro packages that nobody ever
downloads.

Exactly, isn't that how you maintain an architecture downstream: You
make sure it is working for any users to come by. What's the problem
with that? And is that any different for most other architectures? How
many of the maybe 60k (?) packages for x86 on Debian are actually used
by users?

Look, Debian is not RHEL or SLES. It (or the support for it) is not sold
for money, so it is not produced for demand or specialized for
profitable markets. The same's valid for Gentoo I'd say.

But I figure, building a distribution out of kernel, bootloader and
userland and try to keep it in shape is not a legitimate use case?

For the Linux kernel itself, the situation is quite similar. There is
a non-zero effort involved in keeping things working, and if anyone
still needs to run their programs on Itanium, it is not clear to me
why that would require a recent version of the OS.

So bottom line: I am proposing we drop support for Itanium across the
board. Would anyone have any problems with that?

Of course I would have a problem with that. AFAIK GNU/Linux is the last
free OS for these machines. And I don't see those machines as museum
pieces yet, but as options for interested people, coming back to the
hammer and nail thing from above.

By 'interested people' you mean other people than yourself, right?

Is that a rhetorical question?

But I demand nothing of you. And to be honest I can't contribute at this
level to ia64, as I just don't have the required expertise for this type
of hacking.

Apart from that I'd like to thank all people involved in keeping those
interesting systems afloat for the good times I had and have on ia64 and
other interesting architectures and machines.

Again, your insight is much appreciated, even if we fundamentally disagree.

You're welcome. :-)

Have a nice weekend all,
Frank

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

* matoro:

There is no user-mode emulation for ia64 in QEMU either. The only
"ongoing" emulation work is Sergei's fork of the old "ski" emulator, but
this is far from QEMU quality or even usable yet: https://github.com/trofi/ski

Yeah, I must have misremembered. Awkward.

So it's a really exclusive club, which makes continued maintenance
efforts even more doubtful.

Anyway, to summarize this thread for Ard: the answer to the question of
if anybody is using these machines for anything other than to
experimentally see if things run or churn out packages is NO. Any
Itanium machines running useful production workloads are on HP-UX/VMS. Possibly Windows Server 2008 or an old RHEL, but unlikely.

RHEL 6 didn't have ia64 anymore. RHEL 5 is out of support. In any
case, the last thing such customers would want (if they existed) is a
rebase from 2.6.18 to a 6.x kernel, or a toolchain upgrade for that
matter. So what we do to current versions really does not matter to hypothetical commercial ia64 Linux users.

The only argument for continued support is as you described, the
argument from the commons, that the ecosystem as a whole benefits from diversity of architectures. All that matters is whether you find this argument convincing. There are some like myself who do, but I am not a kernel maintainer. If you don't, then that should be that.

Some of the variance/diversity isn't actually necessary, though. It's
just that ia64 has some half-done stuff in the tools that no one
bothered to fix, creating complexities elsewhere.

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

SGkgSnVzaHVhLA0KDQpPbiAyMC4wNS4yMyAyMDoxMSwgSm9zaHVhIFNjb2dnaW5zIHdyb3Rl Og0KPiBJIHVzZWQgdG8gZGFpbHkgZHJpdmUgbXkgb3duIHp4NjAwMCAoYW5kIGhhZCBhIHp4 MjAwMCBhbmQgcng1NjcwIGFzIA0KPiB3ZWxsKSBiYWNrIGluIDIwMDgtMjAxMi4gSSB3YXMg cnVubmluZyBHZW50b28gTGludXggb24gaXQgYW5kIGl0IHdhcyBmb3IgDQo+IHRoZSBtb3N0 IHBhcnQgZmluZS4gSSBnb3QgRmlyZWZveCA5IHdvcmtpbmcgYW5kIGV2ZW4gTWluZWNyYWZ0 ISBXaGF0IA0KPiBJJ3ZlIG9ic2VydmVkIGlzIHRoYXQgR0NDJ3Mgc3VwcG9ydCBmb3IgaWE2 NCBzZWVtcyB0byBoYXZlIGJpdCByb3R0ZWQgDQo+IG92ZXIgdGltZSAoSSd2ZSBlbmNvdW50 ZXJlZCBpbnRlcm5hbCBjb21waWxlciBlcnJvcnMgb3ZlcsKgdGhlIHllYXJzIG9uIA0KPiBz ZWVtaW5nbHkgc3RhbmRhcmQgQysrIGNvZGUpLg0KPiANCj4gV2hpbGUgSSBzdGlsbCBoYXZl IHRoZSB6eDYwMDAsIEkgaGF2ZW4ndCBib290ZWQgaW4gYXQgbGVhc3QgNSB5ZWFycy4gSSAN Cj4gZG9uJ3QgZnVsbHkgdHJ1c3QgY29udGVtcG9yYXJ5IHZlcnNpb25zIG9mIEdDQyB0byBu b3QgZ2VuZXJhdGUgDQo+IHBvdGVudGlhbGx5IGdhcmJhZ2UgY29kZSAodW5sZXNzIHRoaW5n cyBoYXZlIGNoYW5nZWQpLg0KDQpJdCBjb3VsZCBpbnRlcmVzdGluZyB0byBzZWUsIGhvdyBp dCBiZWhhdmVzIHdpdGggRGViaWFuIFNpZCBhbmQgTGludXggDQo2LjMueCAoc2VlIFsxXSku IEkgZmlndXJlIHRoZSB6eDYwMDAgaXMgYSByeDI2MDAgaW4gZGlzZ3Vpc2UsIEkgaGF2ZSBh IA0KcngyNjIwIHdvcmtpbmcgYW5kIGJlbGlldmUgdG8gaGF2ZSBzZWVuIG90aGVycyB3aXRo IGEgcngyNjAwIHJlcG9ydGluZyANCnN1Y2Nlc3Mgc29tZSB0aW1lIGFnbyBvbiB0aGlzIGxp c3QuIFdoYXQgSXRhbml1bXMgZG8geW91IGhhdmUgaW4gdGhlcmUsIA0KTWFkaXNvbnMgb3Ig b3JpZ2luYWwgTWNLaW5sZXlzPw0KDQpbMV06IGh0dHBzOi8vbGlzdHMuZGViaWFuLm9yZy9k ZWJpYW4taWE2NC8yMDIzLzA1L21zZzAwMDEwLmh0bWwNCg0KQ2hlZXJzLA0KRnJhbmsNCg==

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

I believe they are Madison 6mb. I know they are not mad9's. The zx6000 I
have is a rx2600 in the workstation plastic. If you pop the panels off and remove the foot it is rack mountable. So your theory is absolutely correct.

I also worked with someone back in the day on IRC and we determined that
the expansion cage in a rx2620 was cross compatible with the rx2600.


On Sat, May 20, 2023, 11:29 Frank Scheiner <frank.scheiner@web.de> wrote:

Hi Jushua,

On 20.05.23 20:11, Joshua Scoggins wrote:

I used to daily drive my own zx6000 (and had a zx2000 and rx5670 as
well) back in 2008-2012. I was running Gentoo Linux on it and it was for the most part fine. I got Firefox 9 working and even Minecraft! What
I've observed is that GCC's support for ia64 seems to have bit rotted
over time (I've encountered internal compiler errors over the years on seemingly standard C++ code).

While I still have the zx6000, I haven't booted in at least 5 years. I don't fully trust contemporary versions of GCC to not generate
potentially garbage code (unless things have changed).

It could interesting to see, how it behaves with Debian Sid and Linux
6.3.x (see [1]). I figure the zx6000 is a rx2600 in disguise, I have a
rx2620 working and believe to have seen others with a rx2600 reporting success some time ago on this list. What Itaniums do you have in there, Madisons or original McKinleys?

[1]: https://lists.debian.org/debian-ia64/2023/05/msg00010.html

Cheers,
Frank

<div dir="auto">I believe they are Madison 6mb. I know they are not mad9&#39;s. The zx6000 I have is a rx2600 in the workstation plastic. If you pop the panels off and remove the foot it is rack mountable. So your theory is absolutely correct. <div dir="
auto"><br></div><div dir="auto"> I also worked with someone back in the day on IRC and we determined that the expansion cage in a rx2620 was cross compatible with the rx2600. </div><div dir="auto"><br><br><div class="gmail_quote" dir="auto"><div dir="
ltr" class="gmail_attr">On Sat, May 20, 2023, 11:29 Frank Scheiner &lt;<a href="mailto:frank.scheiner@web.de">frank.scheiner@web.de</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:
1ex">Hi Jushua,<br>

On 20.05.23 20:11, Joshua Scoggins wrote:<br>
&gt; I used to daily drive my own zx6000 (and had a zx2000 and rx5670 as <br> &gt; well) back in 2008-2012. I was running Gentoo Linux on it and it was for <br>
&gt; the most part fine. I got Firefox 9 working and even Minecraft! What <br> &gt; I&#39;ve observed is that GCC&#39;s support for ia64 seems to have bit rotted <br>
&gt; over time (I&#39;ve encountered internal compiler errors over the years on <br>
&gt; seemingly standard C++ code).<br>
&gt; <br>
&gt; While I still have the zx6000, I haven&#39;t booted in at least 5 years. I <br>
&gt; don&#39;t fully trust contemporary versions of GCC to not generate <br> &gt; potentially garbage code (unless things have changed).<br>

It could interesting to see, how it behaves with Debian Sid and Linux <br> 6.3.x (see [1]). I figure the zx6000 is a rx2600 in disguise, I have a <br> rx2620 working and believe to have seen others with a rx2600 reporting <br> success some time ago on this list. What Itaniums do you have in there, <br> Madisons or original McKinleys?<br>

[1]: <a href="https://lists.debian.org/debian-ia64/2023/05/msg00010.html" rel="noreferrer noreferrer" target="_blank">https://lists.debian.org/debian-ia64/2023/05/msg00010.html</a><br>

Cheers,<br>
Frank<br>
</blockquote></div></div></div>

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

T24gMjAuMDUuMjMgMjA6NDQsIEpvc2h1YSBTY29nZ2lucyB3cm90ZToNCj4gSSBiZWxpZXZl IHRoZXkgYXJlIE1hZGlzb24gNm1iLiBJIGtub3cgdGhleSBhcmUgbm90IG1hZDkncy4gVGhl IHp4NjAwMCBJIA0KPiBoYXZlIGlzIGEgcngyNjAwIGluIHRoZSB3b3Jrc3RhdGlvbiBwbGFz dGljLg0KDQpJIGxpa2UgdGhlIGRlc2lnbiBvZiB0aG9zZSwgaXQgbG9va3Mgc2ltaWxhciB0 byB0aGUgQzgwMDAgYnV0IA0KImNvbXByZXNzZWQiLiA6LSkNCg0KPiBJZiB5b3UgcG9wIHRo ZSBwYW5lbHMgb2ZmIA0KPiBhbmQgcmVtb3ZlIHRoZSBmb290IGl0IGlzIHJhY2sgbW91bnRh YmxlLiBTbyB5b3VyIHRoZW9yeSBpcyBhYnNvbHV0ZWx5IA0KPiBjb3JyZWN0Lg0KPiANCj4g IMKgSSBhbHNvIHdvcmtlZCB3aXRoIHNvbWVvbmUgYmFjayBpbiB0aGUgZGF5IG9uIElSQyBh bmQgd2UgZGV0ZXJtaW5lZCANCj4gdGhhdCB0aGUgZXhwYW5zaW9uIGNhZ2UgaW4gYSByeDI2 MjAgd2FzIGNyb3NzIGNvbXBhdGlibGUgd2l0aCB0aGUgcngyNjAwLg0KDQpZZWFoLCBJIHRo aW5rIHRoZSBycDM0NDAvcnAzNDEwIChsaWtlbHkgZXhhY3Qgc2FtZSBjYXNlIGFuZCBsaWtl bHkgc2FtZSANCnN5c3RlbSBib2FyZCBhcyB0aGUgcngyNjAwKSBjb3VsZCBldmVuIGJlIHRy YW5zZm9ybWVkIGludG8gYW4gcngyNjAwIA0Kd2l0aCBhIGZpcm13YXJlIHVwZ3JhZGUsIHBs dXMgdGhlIEl0YW5pdW1zIG9mIGNvdXJzZS4NCg0KU2FtZSBmb3IgcnA0NDQwIGFuZCByeDQ2 NDAgSSB0aGluay4gQnV0IEkgbmV2ZXIgZm91bmQgb3V0IGlmIHRoYXQgd291bGQgDQphbHNv IHdvcmsgaW4gcmV2ZXJzZS4NCg0KQmFjayB0aGVuIHRoZSBJbnRlZ3JpdGllcyBoYWQgbW9y ZSBpbiBjb21tb24gd2l0aCBIUHMgb2xkZXIgZGVzaWducyANCihsaWtlIHJwMjQ3MCkgdGhh biB3aXRoIHRoZSBQcm9MaWFudHMgdGFrZW4gb3ZlciBmcm9tIENvbXBhcS4gVGhhdCANCmNo YW5nZWQgc29tZXdoYXQgbGF0ZXIgd2l0aCByeDI2NjAgYW5kIG90aGVycyBhbmQgbm90IG9u bHkgb24gdGhlIG91dHNpZGUuDQoNCkNoZWVycywNCkZyYW5rDQo=

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

On Sat, 2023-05-20 at 12:31 -0700, Joshua Scoggins wrote:

LLVM dropped support for ia64 in 3.0.

Yes, that's what I meant to say. I just happened to write the word
»support« twice.

I meant to say:

»Other projects such as LLVM, OpenJDK and Ruby already removed native
code generation support for ia64 although OpenJDK still works using
the Zero port.«

I'm just tired today.

Adrian

--
.''`. 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)

On Sat, 2023-05-20 at 21:22 +0200, John Paul Adrian Glaubitz wrote:

Other projects such as LLVM, OpenJDK and Ruby already support native code generation
support for ia64 although OpenJDK still works using the Zero port.

That should be »already removed native code generation support for ia64«.

Sorry, I'm already tired today. (-_-) zzz

Adrian

--
.''`. 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)

Hello!

On Sat, 2023-05-20 at 18:48 +0200, Florian Weimer wrote:

* matoro:

There is no user-mode emulation for ia64 in QEMU either. The only "ongoing" emulation work is Sergei's fork of the old "ski" emulator, but this is far from QEMU quality or even usable yet: https://github.com/trofi/ski

Yeah, I must have misremembered. Awkward.

So it's a really exclusive club, which makes continued maintenance
efforts even more doubtful.

I have been thinking about this discussion for a while now and my suggestion would be to drop ia64 support from the kernel, GRUB and gcc/binutils/glibc in this order:

- Kernel: After the next LTS release
- GRUB: After the 2.12 release
- gcc/binutils/glibc: After support was dropped from the kernel

This way anyone still using ia64 will be able to use it with a supported codebase
for an extended time and upstream projects have target releases for which they can plan the removal.

Other projects such as LLVM, OpenJDK and Ruby already support native code generation
support for ia64 although OpenJDK still works using the Zero port.

Adrian

--
.''`. 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)

(cc Greg as stable maintainer)

On Sat, 20 May 2023 at 21:23, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

...

I have been thinking about this discussion for a while now and my suggestion would be to drop ia64 support from the kernel, GRUB and gcc/binutils/glibc in this order:

- Kernel: After the next LTS release
- GRUB: After the 2.12 release
- gcc/binutils/glibc: After support was dropped from the kernel

This way anyone still using ia64 will be able to use it with a supported codebase
for an extended time and upstream projects have target releases for which they
can plan the removal.

Yeah, I think this is reasonable. Having a clear agreement on where
the support ends helps both the remaining users and the developers
eager to move on.

My only question is how we would land fixes for ia64 into this Linux
LTS release if there is no upstream any longer to draw from.

Greg, could you comment on this?

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

On Mon, May 22, 2023 at 09:08:35AM +0200, Ard Biesheuvel wrote:

(cc Greg as stable maintainer)

On Sat, 20 May 2023 at 21:23, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

...

I have been thinking about this discussion for a while now and my suggestion
would be to drop ia64 support from the kernel, GRUB and gcc/binutils/glibc in
this order:

- Kernel: After the next LTS release
- GRUB: After the 2.12 release
- gcc/binutils/glibc: After support was dropped from the kernel

This way anyone still using ia64 will be able to use it with a supported codebase
for an extended time and upstream projects have target releases for which they
can plan the removal.

Yeah, I think this is reasonable. Having a clear agreement on where
the support ends helps both the remaining users and the developers
eager to move on.

My only question is how we would land fixes for ia64 into this Linux
LTS release if there is no upstream any longer to draw from.

Greg, could you comment on this?

That would imply that people actually used that arch and code, so why
would it have been removed from Linus's tree?

And there's nothing "special" about LTS releases for features like this,
just drop the code when no one is using it and all is good.

thanks,

greg k-h

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

On Mon, 22 May 2023 at 09:39, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:

On Mon, May 22, 2023 at 09:08:35AM +0200, Ard Biesheuvel wrote:

(cc Greg as stable maintainer)

On Sat, 20 May 2023 at 21:23, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

...

I have been thinking about this discussion for a while now and my suggestion
would be to drop ia64 support from the kernel, GRUB and gcc/binutils/glibc in
this order:

- Kernel: After the next LTS release
- GRUB: After the 2.12 release
- gcc/binutils/glibc: After support was dropped from the kernel

This way anyone still using ia64 will be able to use it with a supported codebase
for an extended time and upstream projects have target releases for which they
can plan the removal.

Yeah, I think this is reasonable. Having a clear agreement on where
the support ends helps both the remaining users and the developers
eager to move on.

My only question is how we would land fixes for ia64 into this Linux
LTS release if there is no upstream any longer to draw from.

Greg, could you comment on this?

That would imply that people actually used that arch and code, so why
would it have been removed from Linus's tree?

As far as we have been able to establish, the only people that use
this arch and code are people that would hate to see it go, but don't
actually use it for anything other than checking whether it still
boots, and don't have the skills or bandwidth to step up and maintain
it upstream.

And there's nothing "special" about LTS releases for features like this,
just drop the code when no one is using it and all is good.

Fair enough.

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

On Mon, May 22, 2023 at 09:46:57AM +0200, Ard Biesheuvel wrote:

On Mon, 22 May 2023 at 09:39, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:

On Mon, May 22, 2023 at 09:08:35AM +0200, Ard Biesheuvel wrote:

(cc Greg as stable maintainer)

On Sat, 20 May 2023 at 21:23, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

...

I have been thinking about this discussion for a while now and my suggestion
would be to drop ia64 support from the kernel, GRUB and gcc/binutils/glibc in
this order:

- Kernel: After the next LTS release
- GRUB: After the 2.12 release
- gcc/binutils/glibc: After support was dropped from the kernel

This way anyone still using ia64 will be able to use it with a supported codebase
for an extended time and upstream projects have target releases for which they
can plan the removal.

Yeah, I think this is reasonable. Having a clear agreement on where
the support ends helps both the remaining users and the developers
eager to move on.

My only question is how we would land fixes for ia64 into this Linux
LTS release if there is no upstream any longer to draw from.

Greg, could you comment on this?

That would imply that people actually used that arch and code, so why
would it have been removed from Linus's tree?

As far as we have been able to establish, the only people that use
this arch and code are people that would hate to see it go, but don't actually use it for anything other than checking whether it still
boots, and don't have the skills or bandwidth to step up and maintain
it upstream.

Great, then let's drop it today, there is no need to wait until the end
of the year as nothing is going to change then.

thanks,

greg k-h

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

On Mon, May 22, 2023 at 05:27:23PM +0000, Luck, Tony wrote:

As far as we have been able to establish, the only people that use
this arch and code are people that would hate to see it go, but don't
actually use it for anything other than checking whether it still
boots, and don't have the skills or bandwidth to step up and maintain
it upstream.

Great, then let's drop it today, there is no need to wait until the end
of the year as nothing is going to change then.

I think this also puts the existing stable and LTS trees in some interesting state. After arch/ia64 is removed, there may be some tree-wide change
that gets backported to stable & LTS. That may break arch/ia64 in those
trees (e.g. because arguments to some common function are changed).

Maybe just deal with that if it happens ... and if anyone notices ... are there
automated builds and boot test for ia64 in those trees?

Guenter builds for that, but really, if the tree breaks and no one
notices, is it really broken? :)

We handle this all the time in other types of removals (drivers,
subsystems, etc.) I doubt this tiny amount of arch code will matter
much in the long run.

thanks,

greg k-h

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