From: Florian Weimer <fw@deneb.enyo.de>
To: linux-ia64@vger.kernel.org
Subject: Re: [crosspost] dropping support for ia64
Date: Wed, 17 May 2023 19:39:39 +0000 [thread overview]
Message-ID: <87bkiilpc4.fsf@mid.deneb.enyo.de> (raw)
In-Reply-To: <CAMj1kXFCMh_578jniKpUtx_j8ByHnt=s7S+yQ+vGbKt9ud7+kQ@mail.gmail.com>
* 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.
next prev parent reply other threads:[~2023-05-17 19:39 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 [this message]
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=87bkiilpc4.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.