All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Weimer <fw@deneb.enyo.de>
To: linux-ia64@vger.kernel.org
Subject: Re: [crosspost] dropping support for ia64
Date: Sat, 20 May 2023 16:48:25 +0000	[thread overview]
Message-ID: <87y1lj0x0m.fsf@mid.deneb.enyo.de> (raw)
In-Reply-To: <CAMj1kXFCMh_578jniKpUtx_j8ByHnt=s7S+yQ+vGbKt9ud7+kQ@mail.gmail.com>

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

  parent reply	other threads:[~2023-05-20 16:48 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
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 [this message]
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=87y1lj0x0m.fsf@mid.deneb.enyo.de \
    --to=fw@deneb.enyo.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.