[crosspost] dropping support for ia64

[crosspost] dropping support for ia64

[Ard Biesheuvel]

(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.

Re: [crosspost] dropping support for ia64

[Jesse Dougherty]

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
Jesse Dougherty
Cypress Technology Inc



On 5/12/23 11: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.
>
> 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.

RE: [crosspost] dropping support for ia64

[Luck, Tony]

PiBJJ20gYSBsaXR0bGUgYmlhcyBiZWNhdXNlIG15IGNvbXBhbnkgaXMgYSByZS1zZWxsZXJzIG9m
IHRoZSBIUCBJdGFuaXVtIA0KPiBpYTY0IGhhcmR3YXJlIChSWCAmIFpYIGJveGVzKSwgYXMgd2Vs
bCBhcyBQQS1SSVNDLiBGb3IgdGhhdCByZWFzb24sIEkgDQo+IHdvdWxkIGhhdGUgdG8gc2VlIGl0
IGZhZGUgYXdheSBpbiBhbnkgc2VjdG9yLiBUaGUgaWE2NCBwbGF0Zm9ybSBpcyBzdGlsbCANCj4g
d2lkZWx5IHVzZWQgd2l0aCBIUC1VWCBVbml4IGFuZCBPcGVuIFZNUyB1c2VycyB3b3JsZHdpZGUu
IA0KDQpCdXQgaXMgYW55b25lIGRlcGxveWluZyBMaW51eCB2Ni54IGtlcm5lbHMgaW4gcHJvZHVj
dGlvbiBlbnZpcm9ubWVudHM/DQoNCi1Ub255DQoNCg=

Re: [crosspost] dropping support for ia64

[Ard Biesheuvel]

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?

Re: [crosspost] dropping support for ia64

[Frank Scheiner]

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

Re: [crosspost] dropping support for ia64

[Florian Weimer]

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

Re: [crosspost] dropping support for ia64

[Ard Biesheuvel]

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.

Re: [crosspost] dropping support for ia64

[matoro]

On 2023-05-17 15:39, Florian Weimer wrote:
> * 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.

FYI, QEMU does not have ia64 host or target support, not even TCG.

Re: [crosspost] dropping support for ia64

[Frank Scheiner]

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

Re: [crosspost] dropping support for ia64

[Frank Scheiner]

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

Re: [crosspost] dropping support for ia64

[matoro]

On 2023-05-19 16:17, Frank Scheiner wrote:
> Dear matoro, Florian,
> 
> On 17.05.23 23:47, matoro wrote:
>> On 2023-05-17 15:39, Florian Weimer wrote:
>>> * 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.
>> 
>> FYI, QEMU does not have ia64 host or target support, not even TCG.
> 
> I assume Florian means user mode emulation, which for example can be 
> used to complete a `debootstrap --foreign [...]` run when you don't 
> have an existing ia64 userland on real hardware at hand.
> 
> I doubt that it works in the exact same way than the real thing, 
> though. Such differences are part of the reasons why the OpenBSD devs 
> don't seem to use cross compilers or virtualized or emulated systems to 
> produce and test their OS, though they seem to use cross compilers for 
> the bringup of new platforms IIC.
> 
> But if it's good enough to run ia64 binaries on other arches, why not.
> 
> Have a nice weekend,
> Frank

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

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.

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.

Re: [crosspost] dropping support for ia64

[Florian Weimer]

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

Re: [crosspost] dropping support for ia64

[John Paul Adrian Glaubitz]

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

Re: [crosspost] dropping support for ia64

[John Paul Adrian Glaubitz]

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

Re: [crosspost] dropping support for ia64

[John Paul Adrian Glaubitz]

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

Re: [crosspost] dropping support for ia64

[Ard Biesheuvel]

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

Re: [crosspost] dropping support for ia64

[Greg Kroah-Hartman]

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

Re: [crosspost] dropping support for ia64

[Ard Biesheuvel]

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.

Re: [crosspost] dropping support for ia64

[Greg Kroah-Hartman]

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

RE: [crosspost] dropping support for ia64

[Luck, Tony]

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

-Tony

Re: [crosspost] dropping support for ia64

[Greg Kroah-Hartman]

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