Am 2020-11-17 23:32, schrieb Alex Xu (Hello71):
bzip2 is either slower or larger than every other supported algorithm, according to benchmarks at [0]. It is far slower to decompress than any other algorithm, and still larger than lzma, xz, and zstd.
diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst index abb9fc164657..b74d14caabe6 100644 --- a/Documentation/x86/boot.rst +++ b/Documentation/x86/boot.rst @@ -781,10 +781,10 @@ Protocol: 2.08+ The payload may be compressed. The format of both the compressed and uncompressed data should be determined using the standard magic numbers. The currently supported compression formats are gzip - (magic numbers 1F 8B or 1F 9E), bzip2 (magic number 42 5A), LZMA - (magic number 5D 00), XZ (magic number FD 37), LZ4 (magic number - 02 21) and ZSTD (magic number 28 B5). The uncompressed payload is - currently always ELF (magic number 7F 45 4C 46). + (magic numbers 1F 8B or 1F 9E), LZMA (magic number 5D 00), XZ (magic + number FD 37), LZ4 (magic number 02 21) and ZSTD (magic number 28 + B5). The uncompressed payload is currently always ELF (magic number + 7F 45 4C 46). ============ ============== Field name: payload_length diff --git a/arch/arm/configs/aspeed_g4_defconfig b/arch/arm/configs/aspeed_g4_defconfig index 58d293b63581..f2f5dcd0e59c 100644
I would keep the magic number, and just tell that it is not supported by newer kernels anymore if at all. It's just handy to be able to look into the most recent documentation and see what the values are for. If you look at an older image and don't find the magic number my first impulse would not be to look at older versions of the documentation for things that were removed.
Maybe something like: "Formerly supported was also bzip2 (magic number 42 5A)." Eike
