F41 Change Proposal: acpica-tools: Deprecate Big Endian Support (System-Wide)

Change Proposal Name: acpica-tools: Deprecate Big Endian Support

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.


:link: Summary

The acpica-tools package has supported big-endian architectures for several years, but it has few uses. For Fedora 41, remove all of the patches for big-endian support and remove s390x from the list of supported architectures.

:link: Owner

:link: Detailed Description

For many years, the acpica-tools package has supported the big-endian s390x architecture, despite ACPI being a little-endian only standard. This made sense originally, as some s390x packages had to have mechanisms for dealing with ACPI tables, and there were several packages with build dependencies since they created ACPI tables. Neither of these is really true any longer.

What’s more, big-endian support has always had a fairly high cost. In the first place, upstream wants nothing to do with big-endian support; it is completely irrelevant, despite several attempts to get them to accept it. Secondly, every release of the upstream source requires significant backporting of the big-endian patches, creating new patches to support new features of, or changes in, the ACPI standard, and then testing and debugging the results. In the last ten years, the least amount of time to do this was two full days; the longest it has taken has been two full weeks. One has to plan for at least a week. And finally, the need for big-endian has diminished considerably. At one point, some virtualization functions required these tools so that there was no virtualization on s390x without them; again, this is no longer true.

The actual changes to the acpica-tools package will actually simplify maintenance significantly. The change itself is fairly straightforward: remove the big-endian patches, and add s390x to ExcludeArch.

:link: Feedback

This proposal was actually prompted by a recent PR on acpica-tools requesting a way to ignore the big-endian patches: [1]. Upstream has never accepted big-endian support. Should this proposal be accepted, it would be one way of meeting the request behind the PR, however. Some discussion has occurred with s390x supporters (both recently, and in the past) that would indicate this would be something that is not ideal (no one likes to lose packages), but doesn’t really create problems. Part of the reason for making this proposal is to be sure I’m not missing something.

:link: Benefit to Fedora

The primary benefit to this proposal is that it simplifies maintenance significantly. Of the 69 patches for the package, 49 can simply be removed. The longest and most difficult builds will not be needed; the s390x testing that always takes most of the package update time will no longer be needed either. This will make it easier to ensure that acpica-tools more closely matches upstream than has been possible recently, producing a higher quality package quicker.

:link: Scope

  • Proposal owners: The actual changes to the acpica-tools package will be to remove the big-endian patches, and add s390x to ExcludeArch. This is quite straightforward.
  • Other developers: Based on an initial investigation, it appears that most changes will be to simply exclude s390x. So far, the only packages that seem to be affected are hw-probe, vim-syntastic-asl, and edk2. There appears to be some use outside of Fedora (xorg-x11-drv-nvidia, their proprietary drivers, for some reason).
  • Release engineering: This change only affects the specific packages mentioned so far.
  • Policies and guidelines: N/A
  • Trademark approval: N/A

:link: Upgrade/compatibility impact

Only s390x systems would notice a change in that this package would no longer be available.

:link: How To Test

There is a test suite included in the acpica-tools package that is always run as part of the %check step in the spec file. No new testing should be required.

:link: User Experience

Only s390x systems would notice a change in that this package would no longer be available.

:link: Dependencies

The packages hw-probe, vim-syntastic-asl, and edk2 depend on acpica-tools. However, to make the changes to acpica-tools, there are no other dependencies.

:link: Contingency Plan

  • Contingency mechanism: do nothing; the existing f40 package can continue to be used.
  • Contingency deadline: beta freeze
  • Blocks release? No

:link: Documentation

These changes actually put the Fedora version of the package back into a state where it matches upstream more closely.

:link: Release Notes

Last edited by @amoloney 2024-06-24T10:53:24Z

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply giving that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

edk2: has ‘ExclusiveArch: x86_64 aarch64 riscv64’, i.e. it is build only on platforms which actually use UEFI+ACPI. So not affected by removing acpica-tools on s390x.

qemu: test cases can (optionally) use iasl for better diagnostics in case of acpi test case failures (decompile mismatching aml + show asl diff). These tests actually run on s390x (because you can use qemu @ s390x to emulate x86 / arm guests). Nevertheless I would not consider iasl support @ s390x essential here.

This change proposal has now been submitted to FESCo with ticket #3239 for voting.

To find out more, please visit our Changes Policy documentation.

1 Like

This change has been accepted by FESCo for Fedora Linux 41. A full list of approved changes to date can be found on the Change Set Page.

To find out more about how our changes policy works, please visit our docs site.