[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <a9a7fc22ea6fb6bdeb3274fe05a7f0d9@sf-tec.de>
Date: Thu, 19 Nov 2020 10:21:12 +0100
From: Rolf Eike Beer <eike-kernel@...tec.de>
To: "Alex Xu (Hello71)" <alex_y_xu@...oo.ca>
Cc: linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-aspeed@...ts.ozlabs.org, linux-mips@...r.kernel.org,
openrisc@...ts.librecores.org, linux-parisc@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, linux-riscv@...ts.infradead.org,
linux-s390@...r.kernel.org, linux-sh@...r.kernel.org,
linux-xtensa@...ux-xtensa.org, torvalds@...ux-foundation.org
Subject: Re: [RFC PATCH] treewide: remove bzip2 compression support
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
Powered by blists - more mailing lists