Re: [PATCH v2 1/6] ia64: Remove support

[Lennart Sorensen]

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