Linux EFI Zboot Abandoning "Compression Library Museum", Focusing On Gzip & Zstd
([Linux Kernel] 2 Hours Ago
EFI Zboot)
- Reference: 0001510995
- News link: https://www.phoronix.com/news/Linux-EFI-Zboot-Gzip-Zstd
- Source link:
The Linux kernel [1]EFI Zboot code for carrying the Linux kernel image for EFI systems in compressed form is doing away with its "compression library museum" of offering Gzip, LZ4, LZMA, LZO, XZ, and Zstd compression options to instead just focus on Gzip and Zstd compression support.
Rather than offfering many different compression options for the EFI Zboot code, a patch working its way to the mainline kernel is reducing it down to just two choices for compression: Gzip or Zstd. Ard Biesheuvel explains in the patch limiting the compression options to Gzip and Zstd:
"For historical reasons, the legacy decompressor code on various architectures supports 7 different compression types for the compressed kernel image.
EFI zboot is not a compression library museum, and so the options can be limited to what is likely to be useful in practice:
- GZIP is tried and tested, and is still one of the fastest at decompression time, although the compression ratio is not very high; moreover, Fedora is already shipping EFI zboot kernels for arm64 that use GZIP, and QEMU implements direct support for it when booting a kernel without firmware loaded;
- ZSTD has a very high compression ratio (although not the highest), and is almost as fast as GZIP at decompression time.
Reducing the number of options makes it less of a hassle for other consumers of the EFI zboot format (such as QEMU today, and kexec in the future) to support it transparently without having to carry 7 different decompression libraries."
A wise decision to just focus on Gzip and Zstd and to get rid of all the other superfluous options these days... Now if only the Zstd code within the Linux kernel would rebase against the latest upstream state...
The patch to limit the compression options has been queued into [2]efi.git's "urgent" Git branch . With it queued in the "urgent" code rather than its "next" branch, it's likely to be submitted in the coming days for the ongoing Linux 6.13 cycle rather than holding off until the 6.14 cycle. This change only affects EFI Zboot and doesn't impact the compression/decompression options for other areas of the Linux kernel.
[1] https://www.phoronix.com/news/Linux-6.1-Generic-EFI-Zboot
[2] https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/commit/?h=urgent&id=0b2c29fb68f8bf3e87a9d88404aa6fdd486223e5
Rather than offfering many different compression options for the EFI Zboot code, a patch working its way to the mainline kernel is reducing it down to just two choices for compression: Gzip or Zstd. Ard Biesheuvel explains in the patch limiting the compression options to Gzip and Zstd:
"For historical reasons, the legacy decompressor code on various architectures supports 7 different compression types for the compressed kernel image.
EFI zboot is not a compression library museum, and so the options can be limited to what is likely to be useful in practice:
- GZIP is tried and tested, and is still one of the fastest at decompression time, although the compression ratio is not very high; moreover, Fedora is already shipping EFI zboot kernels for arm64 that use GZIP, and QEMU implements direct support for it when booting a kernel without firmware loaded;
- ZSTD has a very high compression ratio (although not the highest), and is almost as fast as GZIP at decompression time.
Reducing the number of options makes it less of a hassle for other consumers of the EFI zboot format (such as QEMU today, and kexec in the future) to support it transparently without having to carry 7 different decompression libraries."
A wise decision to just focus on Gzip and Zstd and to get rid of all the other superfluous options these days... Now if only the Zstd code within the Linux kernel would rebase against the latest upstream state...
The patch to limit the compression options has been queued into [2]efi.git's "urgent" Git branch . With it queued in the "urgent" code rather than its "next" branch, it's likely to be submitted in the coming days for the ongoing Linux 6.13 cycle rather than holding off until the 6.14 cycle. This change only affects EFI Zboot and doesn't impact the compression/decompression options for other areas of the Linux kernel.
[1] https://www.phoronix.com/news/Linux-6.1-Generic-EFI-Zboot
[2] https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/commit/?h=urgent&id=0b2c29fb68f8bf3e87a9d88404aa6fdd486223e5
geerge