News › linux
By The Linux Camp News, October 19, 2026
The October 16 submission replaces an already-BROKEN arm64 configuration with enforced little-endian builds. It simplifies kernel development but leaves no upstream build path for big-endian kernels in the submitted code.
The October 16, 2026 arm64 pull request for Linux 7.4 includes removal of big-endian kernel support for 64-bit ARM. The submission retires an implementation already marked BROKEN rather than withdrawing a normally supported build option. As of the sources retrieved October 19, the evidence establishes a pull request, not acceptance into Linus Torvalds's tree or a released Linux 7.4 kernel. 2
Phoronix dates the BROKEN designation to September 2025, reporting that these configurations were exceptionally rare and lacked developer interest and testing. The maintainer's submission confirms the existing dependency on BROKEN, but does not explain particular failures. That distinction matters: this is retirement of an unmaintained configuration, not a newly documented failure affecting all arm64 kernels. 1 2
Previously, the big-endian implementation remained in the source behind the BROKEN configuration dependency. The submitted changes delete that alternative implementation across hypervisor code, BPF compilation, assembly, cryptography, library routines, endianness helpers and selftests, then enforce little-endian builds. Consequently, restoring a configuration selection alone would not restore the removed kernel build path. 2
The direct compatibility issue is for workflows requiring a big-endian arm64 kernel; little-endian becomes the enforced build mode. The reported benefit is for kernel developers, who have fewer implementation and testing combinations to accommodate. Phoronix describes a maintenance simplification, not a measured runtime speedup. 2 1
For migration planning, the supported boundary is kernel build support. The submission does not establish the implications for big-endian userspace or guests, nor provide a migration procedure for remaining deployments. Operators should therefore not interpret this removal as evidence that every big-endian data-handling capability disappears: the stated change is narrower. 2