All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesse Dougherty <Jesse@Cypress-Tech.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [crosspost] dropping support for ia64
Date: Fri, 12 May 2023 18:50:04 +0000	[thread overview]
Message-ID: <8fea5127-c985-8057-2654-9001cb6256c0@Cypress-Tech.com> (raw)
In-Reply-To: <CAMj1kXFCMh_578jniKpUtx_j8ByHnt=s7S+yQ+vGbKt9ud7+kQ@mail.gmail.com>

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.

  reply	other threads:[~2023-05-12 18:50 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 [this message]
2023-05-12 19:24 ` Luck, Tony
2023-05-12 20:02 ` Ard Biesheuvel
2023-05-17 18:38 ` Frank Scheiner
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=8fea5127-c985-8057-2654-9001cb6256c0@Cypress-Tech.com \
    --to=jesse@cypress-tech.com \
    --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.