From fw at deneb.enyo.de Sat May 20 16:48:25 2023 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 20 May 2023 18:48:25 +0200 Subject: [crosspost] dropping support for ia64 In-Reply-To: <5e778e16f93f2286fa535597ba5da24b@matoro.tk> (matoro's message of "Fri, 19 May 2023 16:56:36 -0400") References: <59a76177-8ed4-e71e-9b11-a673298b5b4b@web.de> <87bkiilpc4.fsf@mid.deneb.enyo.de> <4e210d61adbe73a1673f113019401e5c@matoro.tk> <12a3e3c5-9465-c97f-58ab-938e80681fbc@web.de> <5e778e16f93f2286fa535597ba5da24b@matoro.tk> Message-ID: <87y1lj0x0m.fsf@mid.deneb.enyo.de> * 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. From glaubitz at physik.fu-berlin.de Sat May 20 19:49:37 2023 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Sat, 20 May 2023 21:49:37 +0200 Subject: [crosspost] dropping support for ia64 In-Reply-To: References: <59a76177-8ed4-e71e-9b11-a673298b5b4b@web.de> <87bkiilpc4.fsf@mid.deneb.enyo.de> <4e210d61adbe73a1673f113019401e5c@matoro.tk> <12a3e3c5-9465-c97f-58ab-938e80681fbc@web.de> <5e778e16f93f2286fa535597ba5da24b@matoro.tk> <87y1lj0x0m.fsf@mid.deneb.enyo.de> Message-ID: <1e56d42a19ea3a4fdf844ecae54988f93a5e8558.camel@physik.fu-berlin.de> 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