Re: [PATCH v2 1/6] ia64: Remove support
On Fri, May 12, 2023 at 12:41:47 +0200, John Paul Adrian Glaubitz wrote: > Hello Ard! > > On Thu, 2023-05-11 at 16:29 +0200, Ard Biesheuvel wrote: > > > > Feel free to keep using it, but please stop demanding that our people > > > > keep wasting their time on it. If you want to support it in Debian, > > > > you can carry it as a downstream patch and shoulder the maintenance > > > > burden. > > > > > > Who is "our people"? Do you think that you are part of the community and > > > I am not? I don't think this kind of hostility is justified. Neither you > > > nor I own this project. > > > > > > > Apologies - I had meant to type 'other people' not 'our people'. I > > rarely contribute to GRUB myself, so I wouldn't consider myself more a > > part of this community than anyone else. > > > > But my point remains: I have inferred from your response (and your > > involvement in similar discussions around the Linux kernel) that you > > would prefer Itanium support to be retained, right? > > Not necessarily. I am generally not opposed to removing ia64 support, but it > should happen in a coordinated form where downstreams and users are involved. > > Just dropping support from random projects without prior coordination seems > like the wrong approach to me. I would suggest posting your plans to the > distributions mailing list [1], Debian's ia64 mailing list [2], the Gentoo > developer mailing list [3], the Linux ia64 mailing list [4] and maybe the > NetBSD ia64 mailing list [5]. > > If you don't get any objections there, I am not going to object either. I just > want this to happen in an ordered manner. > For future reference, might I suggest the following "distributions" list as well: distributi...@lists.linux.dev It's a relatively new list for cross-distro collaboration/PSAs. You can find the archives here [6]. - Oskari > > So could you explain who you think should carry the maintenance > > burden? IA64 will be the only EFI architecture in GRUB that does not > > boot via an EFI stub in Linux, and this deviation means that retaining > > support for it is going to take actual developer and maintainer > > bandwidth. GRUB gets very little of that as it is, which means that > > keeping IA64 support alive comes at the cost of worse support for > > other architectures and platforms. (The series that this patch is part > > of breaks the ia64 build, and i i struggle to see why i should care > > about that) > > > > Very few of those people have access to such systems to begin with > > (probably none), and the companies that manufactured them stopped > > supporting them in the open source years ago, so testing these changes > > is not straight-forward, making it unreasonable to demand this from > > contributors. Also, it is unclear to me why the needs of the few > > people that do still run such a system are not served by a build based > > on today's GRUB tree, and why ia64 support needs to be retained going > > forward. > > Well, that's why I am suggesting to coordinate this properly and ask potential > users of the code whether they are okay with the removal. > > Thanks, > Adrian > > [1] https://lists.freedesktop.org/mailman/listinfo/distributions > [2] https://lists.debian.org/debian-ia64/ > [3] https://archives.gentoo.org/gentoo-dev/ > [4] https://marc.info/?l=linux-ia64=1=1 > [5] https://mail-index.netbsd.org/port-ia64/tindex.html > [6] https://lore.kernel.org/distributions/ > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer > `. `' Physicist > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel signature.asc Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 1/6] ia64: Remove support
On 2023-05-12 05:49, Ard Biesheuvel wrote: On Fri, 12 May 2023 at 00:41, matoro wrote: On 2023-05-11 18:09, Ard Biesheuvel wrote: > On Thu, 11 May 2023 at 20:59, matoro > wrote: >> >> On 2023-05-11 10:29, Ard Biesheuvel wrote: >> > On Thu, 11 May 2023 at 15:34, John Paul Adrian Glaubitz >> > wrote: >> >> >> >> On Thu, 2023-05-11 at 14:17 +0200, Ard Biesheuvel wrote: >> >> > On Thu, 11 May 2023 at 14:14, John Paul Adrian Glaubitz >> >> > wrote: >> >> > > >> >> > > On Thu, 2023-05-11 at 14:06 +0200, Ard Biesheuvel wrote: >> >> > > > Itanium IA-64 support is obsolete, and implements its own flavor of EFI >> >> > > > boot that deviates from other architectures. Given that IA64 is unused >> >> > > > and unmaintained, it makes no sense to pretend that the EFI changes we >> >> > > > are making are tested or supported on IA64, so let's just get rid of it. >> >> > > >> >> > > But I just recently tested GRUB from git on IA64 and it worked without >> >> > > any problems. We're using GRUB to boot Debian on IA64. >> >> > > >> >> > >> >> > IA-64 is a dead platform, and a waste of electricity. >> >> >> >> I was just making a statement regarding the testability of the code. >> >> That's all. >> >> >> > >> > Fair enough. That is good to know actually - that way, we have a known >> > working state right before we remove it. >> > >> >> > Feel free to keep using it, but please stop demanding that our people >> >> > keep wasting their time on it. If you want to support it in Debian, >> >> > you can carry it as a downstream patch and shoulder the maintenance >> >> > burden. >> >> >> >> Who is "our people"? Do you think that you are part of the community >> >> and >> >> I am not? I don't think this kind of hostility is justified. Neither >> >> you >> >> nor I own this project. >> >> >> > >> > Apologies - I had meant to type 'other people' not 'our people'. I >> > rarely contribute to GRUB myself, so I wouldn't consider myself more a >> > part of this community than anyone else. >> > >> > But my point remains: I have inferred from your response (and your >> > involvement in similar discussions around the Linux kernel) that you >> > would prefer Itanium support to be retained, right? >> > >> > So could you explain who you think should carry the maintenance >> > burden? IA64 will be the only EFI architecture in GRUB that does not >> > boot via an EFI stub in Linux, and this deviation means that retaining >> > support for it is going to take actual developer and maintainer >> > bandwidth. GRUB gets very little of that as it is, which means that >> > keeping IA64 support alive comes at the cost of worse support for >> > other architectures and platforms. (The series that this patch is part >> > of breaks the ia64 build, and i i struggle to see why i should care >> > about that) >> > >> > Very few of those people have access to such systems to begin with >> > (probably none), and the companies that manufactured them stopped >> > supporting them in the open source years ago, so testing these changes >> > is not straight-forward, making it unreasonable to demand this from >> > contributors. Also, it is unclear to me why the needs of the few >> > people that do still run such a system are not served by a build based >> > on today's GRUB tree, and why ia64 support needs to be retained going >> > forward. >> > >> > I'll leave it to the maintainers whether to merge this patch or not, >> > but if this needs to keep working on ia64 as well, someone else will >> > have to step up. >> >> Hi, I also have a functioning GRUB install on ia64 EFI. My machine is >> fully open and available for debugging work, including on kernel and >> bootloader (hard resets can be done via management console). >> >> If there is any way this support can be saved or at least delayed by >> providing real hardware to work on, please reach out. The environment >> is completely remote and available for anybody who would like to give >> it >> a try. > > Thanks, this could be helpful if we manage to find people that have > the bandwidth to keep working on this. Would you be willing to spend > time and development effort yourself on building and installing GRUB > from the upstream repository on this machine (which is a bit more > complicated than running kernels or user space programs)? Which distro > and version are you using btw? Yes, of course. I am running Gentoo (rolling), so everything is already built from source anyway. Updating to the latest git revision and adding drop-in patches are both part of the package manager and can be done in a single command. > And just out of curiosity, why does this matter to you? Given that the > ia64 firmware, the hardware and the linux boot protocol have not > changed in a decade, wouldn't it make much more sense to stick with a > stable, current version of GRUB, assuming that these are machines that > need to be kept in working order? What kind of workloads are you > running on these machines? I am simply an
Re: [PATCH v2 1/6] ia64: Remove support
Hi, > - we decide that GRUB 2.xx (whichever was the most recent release at > the time of the decision) is good enough to boot Linux on ia64 for the > remaining life time of the architecture, and remove it from the GRUB > tree. That looks like the most reasonable option to me. Note that ia64 firmware development is dead, upstream edk2 dropped ia64 support years ago. All the efi changes in the pipeline are not relevant for ia64. take care, Gerd ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 1/6] ia64: Remove support
On Fri, 12 May 2023 at 12:42, John Paul Adrian Glaubitz wrote: > > Hello Ard! > > On Thu, 2023-05-11 at 16:29 +0200, Ard Biesheuvel wrote: > > > > Feel free to keep using it, but please stop demanding that our people > > > > keep wasting their time on it. If you want to support it in Debian, > > > > you can carry it as a downstream patch and shoulder the maintenance > > > > burden. > > > > > > Who is "our people"? Do you think that you are part of the community and > > > I am not? I don't think this kind of hostility is justified. Neither you > > > nor I own this project. > > > > > > > Apologies - I had meant to type 'other people' not 'our people'. I > > rarely contribute to GRUB myself, so I wouldn't consider myself more a > > part of this community than anyone else. > > > > But my point remains: I have inferred from your response (and your > > involvement in similar discussions around the Linux kernel) that you > > would prefer Itanium support to be retained, right? > > Not necessarily. I am generally not opposed to removing ia64 support, but it > should happen in a coordinated form where downstreams and users are involved. > Are you aware of any actual users? > Just dropping support from random projects without prior coordination seems > like the wrong approach to me. I would suggest posting your plans to the > distributions mailing list [1], Debian's ia64 mailing list [2], the Gentoo > developer mailing list [3], the Linux ia64 mailing list [4] and maybe the > NetBSD ia64 mailing list [5]. > Fair enough > If you don't get any objections there, I am not going to object either. I just > want this to happen in an ordered manner. > I already sent a similar patch to the linux-ia64 a while ago, and the only person that objected was you :-) > > So could you explain who you think should carry the maintenance > > burden? IA64 will be the only EFI architecture in GRUB that does not > > boot via an EFI stub in Linux, and this deviation means that retaining > > support for it is going to take actual developer and maintainer > > bandwidth. GRUB gets very little of that as it is, which means that > > keeping IA64 support alive comes at the cost of worse support for > > other architectures and platforms. (The series that this patch is part > > of breaks the ia64 build, and i i struggle to see why i should care > > about that) > > > > Very few of those people have access to such systems to begin with > > (probably none), and the companies that manufactured them stopped > > supporting them in the open source years ago, so testing these changes > > is not straight-forward, making it unreasonable to demand this from > > contributors. Also, it is unclear to me why the needs of the few > > people that do still run such a system are not served by a build based > > on today's GRUB tree, and why ia64 support needs to be retained going > > forward. > > Well, that's why I am suggesting to coordinate this properly and ask potential > users of the code whether they are okay with the removal. > That is reasonable - let's see how other people feel about this. -- Ard. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 1/6] ia64: Remove support
Hello Ard! On Thu, 2023-05-11 at 16:29 +0200, Ard Biesheuvel wrote: > > > Feel free to keep using it, but please stop demanding that our people > > > keep wasting their time on it. If you want to support it in Debian, > > > you can carry it as a downstream patch and shoulder the maintenance > > > burden. > > > > Who is "our people"? Do you think that you are part of the community and > > I am not? I don't think this kind of hostility is justified. Neither you > > nor I own this project. > > > > Apologies - I had meant to type 'other people' not 'our people'. I > rarely contribute to GRUB myself, so I wouldn't consider myself more a > part of this community than anyone else. > > But my point remains: I have inferred from your response (and your > involvement in similar discussions around the Linux kernel) that you > would prefer Itanium support to be retained, right? Not necessarily. I am generally not opposed to removing ia64 support, but it should happen in a coordinated form where downstreams and users are involved. Just dropping support from random projects without prior coordination seems like the wrong approach to me. I would suggest posting your plans to the distributions mailing list [1], Debian's ia64 mailing list [2], the Gentoo developer mailing list [3], the Linux ia64 mailing list [4] and maybe the NetBSD ia64 mailing list [5]. If you don't get any objections there, I am not going to object either. I just want this to happen in an ordered manner. > So could you explain who you think should carry the maintenance > burden? IA64 will be the only EFI architecture in GRUB that does not > boot via an EFI stub in Linux, and this deviation means that retaining > support for it is going to take actual developer and maintainer > bandwidth. GRUB gets very little of that as it is, which means that > keeping IA64 support alive comes at the cost of worse support for > other architectures and platforms. (The series that this patch is part > of breaks the ia64 build, and i i struggle to see why i should care > about that) > > Very few of those people have access to such systems to begin with > (probably none), and the companies that manufactured them stopped > supporting them in the open source years ago, so testing these changes > is not straight-forward, making it unreasonable to demand this from > contributors. Also, it is unclear to me why the needs of the few > people that do still run such a system are not served by a build based > on today's GRUB tree, and why ia64 support needs to be retained going > forward. Well, that's why I am suggesting to coordinate this properly and ask potential users of the code whether they are okay with the removal. Thanks, Adrian > [1] https://lists.freedesktop.org/mailman/listinfo/distributions > [2] https://lists.debian.org/debian-ia64/ > [3] https://archives.gentoo.org/gentoo-dev/ > [4] https://marc.info/?l=linux-ia64=1=1 > [5] https://mail-index.netbsd.org/port-ia64/tindex.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 1/6] ia64: Remove support
On Fri, 12 May 2023 at 00:41, matoro wrote: > > On 2023-05-11 18:09, Ard Biesheuvel wrote: > > On Thu, 11 May 2023 at 20:59, matoro > > wrote: > >> > >> On 2023-05-11 10:29, Ard Biesheuvel wrote: > >> > On Thu, 11 May 2023 at 15:34, John Paul Adrian Glaubitz > >> > wrote: > >> >> > >> >> On Thu, 2023-05-11 at 14:17 +0200, Ard Biesheuvel wrote: > >> >> > On Thu, 11 May 2023 at 14:14, John Paul Adrian Glaubitz > >> >> > wrote: > >> >> > > > >> >> > > On Thu, 2023-05-11 at 14:06 +0200, Ard Biesheuvel wrote: > >> >> > > > Itanium IA-64 support is obsolete, and implements its own flavor > >> >> > > > of EFI > >> >> > > > boot that deviates from other architectures. Given that IA64 is > >> >> > > > unused > >> >> > > > and unmaintained, it makes no sense to pretend that the EFI > >> >> > > > changes we > >> >> > > > are making are tested or supported on IA64, so let's just get rid > >> >> > > > of it. > >> >> > > > >> >> > > But I just recently tested GRUB from git on IA64 and it worked > >> >> > > without > >> >> > > any problems. We're using GRUB to boot Debian on IA64. > >> >> > > > >> >> > > >> >> > IA-64 is a dead platform, and a waste of electricity. > >> >> > >> >> I was just making a statement regarding the testability of the code. > >> >> That's all. > >> >> > >> > > >> > Fair enough. That is good to know actually - that way, we have a known > >> > working state right before we remove it. > >> > > >> >> > Feel free to keep using it, but please stop demanding that our people > >> >> > keep wasting their time on it. If you want to support it in Debian, > >> >> > you can carry it as a downstream patch and shoulder the maintenance > >> >> > burden. > >> >> > >> >> Who is "our people"? Do you think that you are part of the community > >> >> and > >> >> I am not? I don't think this kind of hostility is justified. Neither > >> >> you > >> >> nor I own this project. > >> >> > >> > > >> > Apologies - I had meant to type 'other people' not 'our people'. I > >> > rarely contribute to GRUB myself, so I wouldn't consider myself more a > >> > part of this community than anyone else. > >> > > >> > But my point remains: I have inferred from your response (and your > >> > involvement in similar discussions around the Linux kernel) that you > >> > would prefer Itanium support to be retained, right? > >> > > >> > So could you explain who you think should carry the maintenance > >> > burden? IA64 will be the only EFI architecture in GRUB that does not > >> > boot via an EFI stub in Linux, and this deviation means that retaining > >> > support for it is going to take actual developer and maintainer > >> > bandwidth. GRUB gets very little of that as it is, which means that > >> > keeping IA64 support alive comes at the cost of worse support for > >> > other architectures and platforms. (The series that this patch is part > >> > of breaks the ia64 build, and i i struggle to see why i should care > >> > about that) > >> > > >> > Very few of those people have access to such systems to begin with > >> > (probably none), and the companies that manufactured them stopped > >> > supporting them in the open source years ago, so testing these changes > >> > is not straight-forward, making it unreasonable to demand this from > >> > contributors. Also, it is unclear to me why the needs of the few > >> > people that do still run such a system are not served by a build based > >> > on today's GRUB tree, and why ia64 support needs to be retained going > >> > forward. > >> > > >> > I'll leave it to the maintainers whether to merge this patch or not, > >> > but if this needs to keep working on ia64 as well, someone else will > >> > have to step up. > >> > >> Hi, I also have a functioning GRUB install on ia64 EFI. My machine is > >> fully open and available for debugging work, including on kernel and > >> bootloader (hard resets can be done via management console). > >> > >> If there is any way this support can be saved or at least delayed by > >> providing real hardware to work on, please reach out. The environment > >> is completely remote and available for anybody who would like to give > >> it > >> a try. > > > > Thanks, this could be helpful if we manage to find people that have > > the bandwidth to keep working on this. Would you be willing to spend > > time and development effort yourself on building and installing GRUB > > from the upstream repository on this machine (which is a bit more > > complicated than running kernels or user space programs)? Which distro > > and version are you using btw? > > Yes, of course. I am running Gentoo (rolling), so everything is already > built from source anyway. Updating to the latest git revision and > adding drop-in patches are both part of the package manager and can be > done in a single command. > > > And just out of curiosity, why does this matter to you? Given that the > > ia64 firmware, the hardware and the linux boot protocol have not > > changed in a decade, wouldn't it make
Re: [PATCH v2 1/6] ia64: Remove support
On Fri, May 12, 2023 at 12:09:14AM +0200, Ard Biesheuvel wrote: > Thanks, this could be helpful if we manage to find people that have > the bandwidth to keep working on this. Would you be willing to spend > time and development effort yourself on building and installing GRUB > from the upstream repository on this machine (which is a bit more > complicated than running kernels or user space programs)? Which distro > and version are you using btw? > > And just out of curiosity, why does this matter to you? Given that the > ia64 firmware, the hardware and the linux boot protocol have not > changed in a decade, wouldn't it make much more sense to stick with a > stable, current version of GRUB, assuming that these are machines that > need to be kept in working order? What kind of workloads are you > running on these machines? > > For ia64, there are no upsides to running newer GRUB code with changes > applied to the EFI layer, as these involve protocols and other > functionality that the ia64 firmware simply does not implement. In the > best case, it works exactly the same as it does today. In the worst > case, it bricks your box and someone has to go down and reinstall the > bootloader (or more) using some kind of rescue image. Future EFI work > will be focused on tightening memory permissions and implementing > other robustness and hardening improvements, and these changes might > tickle bugs in older firmware in ways we cannot anticipate at this > point. > > So what exactly would we be trying to achieve by keeping ia64 > supported in upstream GRUB? Is it really important enough to justify > asking contributors to spend time and effort on it rather than on > something else? I don't personally care about IA64 (I think the architecture was awful, right from when it was announced), but I don't understand some people's desire to delete code that is working. If the code works, why not leave it alone? Unless it gets in the way of doing some big API change that affects lots of different parts of the code, how does it add to anyone's effort? You don't have to compile test the code if it is only used on an architecture you don't work with. The people that do use that architecture can take care to make sure it still builds and fix it if needed. Now if the code ends up broken and no one actually cares to fix it, OK at that point you should probably remove it, but until it breaks or actually gets in the way (not just in theory), there really doesn't seem to be any reason to delete it. Removing it in fact is work, and if someone else still wants to work with it, you just made their effort even higher. The linux kernel I believe is considering dropping support for 486 recently because it was actually making it harder to maintain locking code. So in that case it is causing a maintenance problem and it seemed quite justified to consider removing it. I don't think they have actually done so yet, but at least they are considering it. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 1/6] ia64: Remove support
On 2023-05-11 18:09, Ard Biesheuvel wrote: On Thu, 11 May 2023 at 20:59, matoro wrote: On 2023-05-11 10:29, Ard Biesheuvel wrote: > On Thu, 11 May 2023 at 15:34, John Paul Adrian Glaubitz > wrote: >> >> On Thu, 2023-05-11 at 14:17 +0200, Ard Biesheuvel wrote: >> > On Thu, 11 May 2023 at 14:14, John Paul Adrian Glaubitz >> > wrote: >> > > >> > > On Thu, 2023-05-11 at 14:06 +0200, Ard Biesheuvel wrote: >> > > > Itanium IA-64 support is obsolete, and implements its own flavor of EFI >> > > > boot that deviates from other architectures. Given that IA64 is unused >> > > > and unmaintained, it makes no sense to pretend that the EFI changes we >> > > > are making are tested or supported on IA64, so let's just get rid of it. >> > > >> > > But I just recently tested GRUB from git on IA64 and it worked without >> > > any problems. We're using GRUB to boot Debian on IA64. >> > > >> > >> > IA-64 is a dead platform, and a waste of electricity. >> >> I was just making a statement regarding the testability of the code. >> That's all. >> > > Fair enough. That is good to know actually - that way, we have a known > working state right before we remove it. > >> > Feel free to keep using it, but please stop demanding that our people >> > keep wasting their time on it. If you want to support it in Debian, >> > you can carry it as a downstream patch and shoulder the maintenance >> > burden. >> >> Who is "our people"? Do you think that you are part of the community >> and >> I am not? I don't think this kind of hostility is justified. Neither >> you >> nor I own this project. >> > > Apologies - I had meant to type 'other people' not 'our people'. I > rarely contribute to GRUB myself, so I wouldn't consider myself more a > part of this community than anyone else. > > But my point remains: I have inferred from your response (and your > involvement in similar discussions around the Linux kernel) that you > would prefer Itanium support to be retained, right? > > So could you explain who you think should carry the maintenance > burden? IA64 will be the only EFI architecture in GRUB that does not > boot via an EFI stub in Linux, and this deviation means that retaining > support for it is going to take actual developer and maintainer > bandwidth. GRUB gets very little of that as it is, which means that > keeping IA64 support alive comes at the cost of worse support for > other architectures and platforms. (The series that this patch is part > of breaks the ia64 build, and i i struggle to see why i should care > about that) > > Very few of those people have access to such systems to begin with > (probably none), and the companies that manufactured them stopped > supporting them in the open source years ago, so testing these changes > is not straight-forward, making it unreasonable to demand this from > contributors. Also, it is unclear to me why the needs of the few > people that do still run such a system are not served by a build based > on today's GRUB tree, and why ia64 support needs to be retained going > forward. > > I'll leave it to the maintainers whether to merge this patch or not, > but if this needs to keep working on ia64 as well, someone else will > have to step up. Hi, I also have a functioning GRUB install on ia64 EFI. My machine is fully open and available for debugging work, including on kernel and bootloader (hard resets can be done via management console). If there is any way this support can be saved or at least delayed by providing real hardware to work on, please reach out. The environment is completely remote and available for anybody who would like to give it a try. Thanks, this could be helpful if we manage to find people that have the bandwidth to keep working on this. Would you be willing to spend time and development effort yourself on building and installing GRUB from the upstream repository on this machine (which is a bit more complicated than running kernels or user space programs)? Which distro and version are you using btw? Yes, of course. I am running Gentoo (rolling), so everything is already built from source anyway. Updating to the latest git revision and adding drop-in patches are both part of the package manager and can be done in a single command. And just out of curiosity, why does this matter to you? Given that the ia64 firmware, the hardware and the linux boot protocol have not changed in a decade, wouldn't it make much more sense to stick with a stable, current version of GRUB, assuming that these are machines that need to be kept in working order? What kind of workloads are you running on these machines? I am simply an enthusiast of alternative architectures. In particular I think it's the only way to keep ourselves honest about portability, and also the only way to ensure that many ecosystems truly build from source, as there's no way to pull down random binary code from the internet on platforms like this. I bought this hardware at great personal expense
Re: [PATCH v2 1/6] ia64: Remove support
On Thu, 11 May 2023 at 20:59, matoro wrote: > > On 2023-05-11 10:29, Ard Biesheuvel wrote: > > On Thu, 11 May 2023 at 15:34, John Paul Adrian Glaubitz > > wrote: > >> > >> On Thu, 2023-05-11 at 14:17 +0200, Ard Biesheuvel wrote: > >> > On Thu, 11 May 2023 at 14:14, John Paul Adrian Glaubitz > >> > wrote: > >> > > > >> > > On Thu, 2023-05-11 at 14:06 +0200, Ard Biesheuvel wrote: > >> > > > Itanium IA-64 support is obsolete, and implements its own flavor of > >> > > > EFI > >> > > > boot that deviates from other architectures. Given that IA64 is > >> > > > unused > >> > > > and unmaintained, it makes no sense to pretend that the EFI changes > >> > > > we > >> > > > are making are tested or supported on IA64, so let's just get rid of > >> > > > it. > >> > > > >> > > But I just recently tested GRUB from git on IA64 and it worked without > >> > > any problems. We're using GRUB to boot Debian on IA64. > >> > > > >> > > >> > IA-64 is a dead platform, and a waste of electricity. > >> > >> I was just making a statement regarding the testability of the code. > >> That's all. > >> > > > > Fair enough. That is good to know actually - that way, we have a known > > working state right before we remove it. > > > >> > Feel free to keep using it, but please stop demanding that our people > >> > keep wasting their time on it. If you want to support it in Debian, > >> > you can carry it as a downstream patch and shoulder the maintenance > >> > burden. > >> > >> Who is "our people"? Do you think that you are part of the community > >> and > >> I am not? I don't think this kind of hostility is justified. Neither > >> you > >> nor I own this project. > >> > > > > Apologies - I had meant to type 'other people' not 'our people'. I > > rarely contribute to GRUB myself, so I wouldn't consider myself more a > > part of this community than anyone else. > > > > But my point remains: I have inferred from your response (and your > > involvement in similar discussions around the Linux kernel) that you > > would prefer Itanium support to be retained, right? > > > > So could you explain who you think should carry the maintenance > > burden? IA64 will be the only EFI architecture in GRUB that does not > > boot via an EFI stub in Linux, and this deviation means that retaining > > support for it is going to take actual developer and maintainer > > bandwidth. GRUB gets very little of that as it is, which means that > > keeping IA64 support alive comes at the cost of worse support for > > other architectures and platforms. (The series that this patch is part > > of breaks the ia64 build, and i i struggle to see why i should care > > about that) > > > > Very few of those people have access to such systems to begin with > > (probably none), and the companies that manufactured them stopped > > supporting them in the open source years ago, so testing these changes > > is not straight-forward, making it unreasonable to demand this from > > contributors. Also, it is unclear to me why the needs of the few > > people that do still run such a system are not served by a build based > > on today's GRUB tree, and why ia64 support needs to be retained going > > forward. > > > > I'll leave it to the maintainers whether to merge this patch or not, > > but if this needs to keep working on ia64 as well, someone else will > > have to step up. > > Hi, I also have a functioning GRUB install on ia64 EFI. My machine is > fully open and available for debugging work, including on kernel and > bootloader (hard resets can be done via management console). > > If there is any way this support can be saved or at least delayed by > providing real hardware to work on, please reach out. The environment > is completely remote and available for anybody who would like to give it > a try. Thanks, this could be helpful if we manage to find people that have the bandwidth to keep working on this. Would you be willing to spend time and development effort yourself on building and installing GRUB from the upstream repository on this machine (which is a bit more complicated than running kernels or user space programs)? Which distro and version are you using btw? And just out of curiosity, why does this matter to you? Given that the ia64 firmware, the hardware and the linux boot protocol have not changed in a decade, wouldn't it make much more sense to stick with a stable, current version of GRUB, assuming that these are machines that need to be kept in working order? What kind of workloads are you running on these machines? For ia64, there are no upsides to running newer GRUB code with changes applied to the EFI layer, as these involve protocols and other functionality that the ia64 firmware simply does not implement. In the best case, it works exactly the same as it does today. In the worst case, it bricks your box and someone has to go down and reinstall the bootloader (or more) using some kind of rescue image. Future EFI work will be focused on tightening memory
Re: [PATCH v2 1/6] ia64: Remove support
On 2023-05-11 10:29, Ard Biesheuvel wrote: On Thu, 11 May 2023 at 15:34, John Paul Adrian Glaubitz wrote: On Thu, 2023-05-11 at 14:17 +0200, Ard Biesheuvel wrote: > On Thu, 11 May 2023 at 14:14, John Paul Adrian Glaubitz > wrote: > > > > On Thu, 2023-05-11 at 14:06 +0200, Ard Biesheuvel wrote: > > > Itanium IA-64 support is obsolete, and implements its own flavor of EFI > > > boot that deviates from other architectures. Given that IA64 is unused > > > and unmaintained, it makes no sense to pretend that the EFI changes we > > > are making are tested or supported on IA64, so let's just get rid of it. > > > > But I just recently tested GRUB from git on IA64 and it worked without > > any problems. We're using GRUB to boot Debian on IA64. > > > > IA-64 is a dead platform, and a waste of electricity. I was just making a statement regarding the testability of the code. That's all. Fair enough. That is good to know actually - that way, we have a known working state right before we remove it. > Feel free to keep using it, but please stop demanding that our people > keep wasting their time on it. If you want to support it in Debian, > you can carry it as a downstream patch and shoulder the maintenance > burden. Who is "our people"? Do you think that you are part of the community and I am not? I don't think this kind of hostility is justified. Neither you nor I own this project. Apologies - I had meant to type 'other people' not 'our people'. I rarely contribute to GRUB myself, so I wouldn't consider myself more a part of this community than anyone else. But my point remains: I have inferred from your response (and your involvement in similar discussions around the Linux kernel) that you would prefer Itanium support to be retained, right? So could you explain who you think should carry the maintenance burden? IA64 will be the only EFI architecture in GRUB that does not boot via an EFI stub in Linux, and this deviation means that retaining support for it is going to take actual developer and maintainer bandwidth. GRUB gets very little of that as it is, which means that keeping IA64 support alive comes at the cost of worse support for other architectures and platforms. (The series that this patch is part of breaks the ia64 build, and i i struggle to see why i should care about that) Very few of those people have access to such systems to begin with (probably none), and the companies that manufactured them stopped supporting them in the open source years ago, so testing these changes is not straight-forward, making it unreasonable to demand this from contributors. Also, it is unclear to me why the needs of the few people that do still run such a system are not served by a build based on today's GRUB tree, and why ia64 support needs to be retained going forward. I'll leave it to the maintainers whether to merge this patch or not, but if this needs to keep working on ia64 as well, someone else will have to step up. Hi, I also have a functioning GRUB install on ia64 EFI. My machine is fully open and available for debugging work, including on kernel and bootloader (hard resets can be done via management console). If there is any way this support can be saved or at least delayed by providing real hardware to work on, please reach out. The environment is completely remote and available for anybody who would like to give it a try. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 1/6] ia64: Remove support
On Thu, 11 May 2023 at 15:34, John Paul Adrian Glaubitz wrote: > > On Thu, 2023-05-11 at 14:17 +0200, Ard Biesheuvel wrote: > > On Thu, 11 May 2023 at 14:14, John Paul Adrian Glaubitz > > wrote: > > > > > > On Thu, 2023-05-11 at 14:06 +0200, Ard Biesheuvel wrote: > > > > Itanium IA-64 support is obsolete, and implements its own flavor of EFI > > > > boot that deviates from other architectures. Given that IA64 is unused > > > > and unmaintained, it makes no sense to pretend that the EFI changes we > > > > are making are tested or supported on IA64, so let's just get rid of it. > > > > > > But I just recently tested GRUB from git on IA64 and it worked without > > > any problems. We're using GRUB to boot Debian on IA64. > > > > > > > IA-64 is a dead platform, and a waste of electricity. > > I was just making a statement regarding the testability of the code. That's > all. > Fair enough. That is good to know actually - that way, we have a known working state right before we remove it. > > Feel free to keep using it, but please stop demanding that our people > > keep wasting their time on it. If you want to support it in Debian, > > you can carry it as a downstream patch and shoulder the maintenance > > burden. > > Who is "our people"? Do you think that you are part of the community and > I am not? I don't think this kind of hostility is justified. Neither you > nor I own this project. > Apologies - I had meant to type 'other people' not 'our people'. I rarely contribute to GRUB myself, so I wouldn't consider myself more a part of this community than anyone else. But my point remains: I have inferred from your response (and your involvement in similar discussions around the Linux kernel) that you would prefer Itanium support to be retained, right? So could you explain who you think should carry the maintenance burden? IA64 will be the only EFI architecture in GRUB that does not boot via an EFI stub in Linux, and this deviation means that retaining support for it is going to take actual developer and maintainer bandwidth. GRUB gets very little of that as it is, which means that keeping IA64 support alive comes at the cost of worse support for other architectures and platforms. (The series that this patch is part of breaks the ia64 build, and i i struggle to see why i should care about that) Very few of those people have access to such systems to begin with (probably none), and the companies that manufactured them stopped supporting them in the open source years ago, so testing these changes is not straight-forward, making it unreasonable to demand this from contributors. Also, it is unclear to me why the needs of the few people that do still run such a system are not served by a build based on today's GRUB tree, and why ia64 support needs to be retained going forward. I'll leave it to the maintainers whether to merge this patch or not, but if this needs to keep working on ia64 as well, someone else will have to step up. -- Ard. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 1/6] ia64: Remove support
On Thu, 2023-05-11 at 14:17 +0200, Ard Biesheuvel wrote: > On Thu, 11 May 2023 at 14:14, John Paul Adrian Glaubitz > wrote: > > > > On Thu, 2023-05-11 at 14:06 +0200, Ard Biesheuvel wrote: > > > Itanium IA-64 support is obsolete, and implements its own flavor of EFI > > > boot that deviates from other architectures. Given that IA64 is unused > > > and unmaintained, it makes no sense to pretend that the EFI changes we > > > are making are tested or supported on IA64, so let's just get rid of it. > > > > But I just recently tested GRUB from git on IA64 and it worked without > > any problems. We're using GRUB to boot Debian on IA64. > > > > IA-64 is a dead platform, and a waste of electricity. I was just making a statement regarding the testability of the code. That's all. > Feel free to keep using it, but please stop demanding that our people > keep wasting their time on it. If you want to support it in Debian, > you can carry it as a downstream patch and shoulder the maintenance > burden. Who is "our people"? Do you think that you are part of the community and I am not? I don't think this kind of hostility is justified. Neither you nor I own this project. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 1/6] ia64: Remove support
On Thu, May 11, 2023 at 02:17:57PM +0200, Ard Biesheuvel wrote: >On Thu, 11 May 2023 at 14:14, John Paul Adrian Glaubitz > wrote: >> >> On Thu, 2023-05-11 at 14:06 +0200, Ard Biesheuvel wrote: >> > Itanium IA-64 support is obsolete, and implements its own flavor of EFI >> > boot that deviates from other architectures. Given that IA64 is unused >> > and unmaintained, it makes no sense to pretend that the EFI changes we >> > are making are tested or supported on IA64, so let's just get rid of it. >> >> But I just recently tested GRUB from git on IA64 and it worked without >> any problems. We're using GRUB to boot Debian on IA64. >> > >IA-64 is a dead platform, and a waste of electricity. > >Feel free to keep using it, but please stop demanding that our people >keep wasting their time on it. If you want to support it in Debian, >you can carry it as a downstream patch and shoulder the maintenance >burden. And I'm not convinced that as the Debian maintainer I care enough. At some point old machines and old architectures die, it's a fact of life. If people insist on keeping their old machines alive for the sake of it, then at some point they also will have to accept staying on old software too. -- Steve McIntyre, Cambridge, UK.st...@einval.com “Changing random stuff until your program works is bad coding practice, but if you do it fast enough it’s Machine Learning.” -- https://twitter.com/manisha72617183 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 1/6] ia64: Remove support
On Thu, 11 May 2023 at 14:14, John Paul Adrian Glaubitz wrote: > > On Thu, 2023-05-11 at 14:06 +0200, Ard Biesheuvel wrote: > > Itanium IA-64 support is obsolete, and implements its own flavor of EFI > > boot that deviates from other architectures. Given that IA64 is unused > > and unmaintained, it makes no sense to pretend that the EFI changes we > > are making are tested or supported on IA64, so let's just get rid of it. > > But I just recently tested GRUB from git on IA64 and it worked without > any problems. We're using GRUB to boot Debian on IA64. > IA-64 is a dead platform, and a waste of electricity. Feel free to keep using it, but please stop demanding that our people keep wasting their time on it. If you want to support it in Debian, you can carry it as a downstream patch and shoulder the maintenance burden. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 1/6] ia64: Remove support
On Thu, 2023-05-11 at 14:06 +0200, Ard Biesheuvel wrote: > Itanium IA-64 support is obsolete, and implements its own flavor of EFI > boot that deviates from other architectures. Given that IA64 is unused > and unmaintained, it makes no sense to pretend that the EFI changes we > are making are tested or supported on IA64, so let's just get rid of it. But I just recently tested GRUB from git on IA64 and it worked without any problems. We're using GRUB to boot Debian on IA64. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v2 1/6] ia64: Remove support
Itanium IA-64 support is obsolete, and implements its own flavor of EFI
boot that deviates from other architectures. Given that IA64 is unused
and unmaintained, it makes no sense to pretend that the EFI changes we
are making are tested or supported on IA64, so let's just get rid of it.
Signed-off-by: Ard Biesheuvel
---
.travis.yml | 7 +-
Makefile.util.def | 1 -
configure.ac | 8 -
docs/grub-dev.texi| 2 +-
docs/grub.texi| 2 +-
gentpl.py | 6 +-
grub-core/Makefile.am | 6 -
grub-core/Makefile.core.def | 15 -
grub-core/commands/file.c | 33 --
grub-core/kern/dl.c | 12 -
grub-core/kern/emu/cache.c| 4 +-
grub-core/kern/emu/cache_s.S | 2 +-
grub-core/kern/emu/lite.c | 3 -
grub-core/kern/ia64/cache.c | 35 --
grub-core/kern/ia64/dl.c | 150 -
grub-core/kern/ia64/dl_helper.c | 241
grub-core/kern/ia64/efi/init.c| 80 ---
grub-core/kern/ia64/efi/startup.S | 44 --
grub-core/kern/misc.c | 2 +-
grub-core/lib/efi/halt.c | 2 +-
grub-core/lib/ia64/longjmp.S | 162 --
grub-core/lib/ia64/setjmp.S | 177 --
grub-core/lib/setjmp.S| 3 -
grub-core/loader/ia64/efi/linux.c | 607
include/grub/cache.h | 2 +-
include/grub/dl.h | 12 +-
include/grub/efi/pe32.h | 2 -
include/grub/elf.h| 109
include/grub/ia64/efi/memory.h| 6 -
include/grub/ia64/efi/time.h | 23 -
include/grub/ia64/kernel.h| 25 -
include/grub/ia64/reloc.h | 44 --
include/grub/ia64/setjmp.h| 28 -
include/grub/ia64/time.h | 28 -
include/grub/ia64/types.h | 32 --
include/grub/misc.h | 2 +-
include/grub/util/install.h | 1 -
include/grub/util/mkimage.h | 2 -
tests/core_compress_test.in | 2 +-
util/grub-install-common.c| 1 -
util/grub-install.c | 16 -
util/grub-mkimage.c | 1 -
util/grub-mkimagexx.c | 175 +-
util/grub-mknetdir.c | 1 -
util/grub-mkrescue.c | 7 -
util/grub-module-verifier.c | 22 -
util/mkimage.c| 17 -
47 files changed, 16 insertions(+), 2146 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 4bd05a30a27ad15c..7bea51b2f0c4da89 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -23,7 +23,7 @@ addons:
env:
global:
# Include all cross toolchain paths, so we can just call them later down.
--
PATH=/tmp/qemu-install/bin:/tmp/grub/bin:/usr/bin:/bin:/tmp/cross/gcc-8.1.0-nolibc/aarch64-linux/bin:/tmp/cross/gcc-8.1.0-nolibc/arm-linux-gnueabi/bin:/tmp/cross/gcc-8.1.0-nolibc/ia64-linux/bin:/tmp/cross/gcc-8.1.0-nolibc/mips64-linux/bin:/tmp/cross/gcc-8.1.0-nolibc/powerpc64-linux/bin:/tmp/cross/gcc-8.1.0-nolibc/riscv32-linux/bin:/tmp/cross/gcc-8.1.0-nolibc/riscv64-linux/bin:/tmp/cross/gcc-8.1.0-nolibc/sparc64-linux/bin
+-
PATH=/tmp/qemu-install/bin:/tmp/grub/bin:/usr/bin:/bin:/tmp/cross/gcc-8.1.0-nolibc/aarch64-linux/bin:/tmp/cross/gcc-8.1.0-nolibc/arm-linux-gnueabi/bin:/tmp/cross/gcc-8.1.0-nolibc/mips64-linux/bin:/tmp/cross/gcc-8.1.0-nolibc/powerpc64-linux/bin:/tmp/cross/gcc-8.1.0-nolibc/riscv32-linux/bin:/tmp/cross/gcc-8.1.0-nolibc/riscv64-linux/bin:/tmp/cross/gcc-8.1.0-nolibc/sparc64-linux/bin
before_script:
# Install necessary toolchains based on $CROSS_TARGETS variable.
@@ -44,7 +44,6 @@ script:
arch=${target%-*};
[ "$arch" = "arm64" ] && arch=aarch64-linux;
[ "$arch" = "arm" ] && arch=arm-linux-gnueabi;
- [ "$arch" = "ia64" ] && arch=ia64-linux;
[ "$arch" = "mipsel" ] && arch=mips64-linux;
[ "$arch" = "powerpc" ] && arch=powerpc64-linux;
[ "$arch" = "riscv32" ] && arch=riscv32-linux;
@@ -83,10 +82,6 @@ matrix:
env:
- GRUB_TARGETS="sparc64-ieee1275"
- CROSS_TARGETS="sparc64-linux"
-- name: "ia64"
- env:
-- GRUB_TARGETS="ia64-efi"
-- CROSS_TARGETS="ia64-linux"
- name: "mips"
env:
- GRUB_TARGETS="mips-arc mipsel-arc mipsel-qemu_mips mips-qemu_mips"
diff --git a/Makefile.util.def b/Makefile.util.def
index beaef1168f0d09b0..ae9e628e5c85b751 100644
--- a/Makefile.util.def
+++ b/Makefile.util.def
@@ -160,7 +160,6 @@ library = {
common = grub-core/io/gzio.c;
common = grub-core/io/xzio.c;
common = grub-core/io/lzopio.c;
- common = grub-core/kern/ia64/dl_helper.c;
common = grub-core/kern/arm/dl_helper.c;
common = grub-core/kern/arm64/dl_helper.c;
common = grub-core/lib/minilzo/minilzo.c;
diff --git a/configure.ac b/configure.ac
index ca42ff8f73182511..789e5658e4d9ab9e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -141,7 +141,6 @@ if test "x$with_platform" = x; then
sparc64-*)
