All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank Scheiner <frank.scheiner@web.de>
To: linux-ia64@vger.kernel.org
Subject: Re: [crosspost] dropping support for ia64
Date: Wed, 17 May 2023 18:38:53 +0000	[thread overview]
Message-ID: <59a76177-8ed4-e71e-9b11-a673298b5b4b@web.de> (raw)
In-Reply-To: <CAMj1kXFCMh_578jniKpUtx_j8ByHnt=s7S+yQ+vGbKt9ud7+kQ@mail.gmail.com>

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


  parent reply	other threads:[~2023-05-17 18:38 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-12 15:57 [crosspost] dropping support for ia64 Ard Biesheuvel
2023-05-12 18:50 ` Jesse Dougherty
2023-05-12 19:24 ` Luck, Tony
2023-05-12 20:02 ` Ard Biesheuvel
2023-05-17 18:38 ` Frank Scheiner [this message]
2023-05-17 19:39 ` Florian Weimer
2023-05-17 21:41 ` Ard Biesheuvel
2023-05-17 21:47 ` matoro
2023-05-19 20:17 ` Frank Scheiner
2023-05-19 20:17 ` Frank Scheiner
2023-05-19 20:56 ` matoro
2023-05-20 16:48 ` Florian Weimer
2023-05-20 19:22 ` John Paul Adrian Glaubitz
2023-05-20 19:27 ` John Paul Adrian Glaubitz
2023-05-20 19:49 ` John Paul Adrian Glaubitz
2023-05-22  7:08 ` Ard Biesheuvel
2023-05-22  7:39 ` Greg Kroah-Hartman
2023-05-22  7:46 ` Ard Biesheuvel
2023-05-22 16:56 ` Greg Kroah-Hartman
2023-05-22 17:27 ` Luck, Tony
2023-05-22 17:38 ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=59a76177-8ed4-e71e-9b11-a673298b5b4b@web.de \
    --to=frank.scheiner@web.de \
    --cc=linux-ia64@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.