Re: [PATCH v3 2/2] initramfs: Allow again choice of the embedded initram compression algorithm

[Andrew Morton]

On Tue, 27 Sep 2016 22:32:59 +0200 klondike <klondike@xxxxxxxxxxxxx> wrote:

> Choosing the appropriate compression option when using an embeded initramfs
> can result in significant size differences in the resulting data.
> 
> This is caused by avoiding double compression of the initramfs contents.
> For example on my tests, choosing CONFIG_INITRAMFS_COMPRESSION_NONE when
> compressing the kernel using XZ) results in up to 500KiB differences (9MiB to
>  8.5MiB) in the kernel size as the dictionary will not get polluted with
> uncomprensible data and may reuse kernel data too.
> 
> Despite embedding an uncompressed initramfs, a user may want to allow for a
> compressed extra initramfs to be passed using the rd system, for example to
> boot a recovery system. Commit 9ba4bcb645898d562498ea66a0df958ef0e7a68c
> ("initramfs: read CONFIG_RD_ variables for initramfs compression") broke
> that behavior by making the choice based on CONFIG_RD_* instead of adding
> CONFIG_INITRAMFS_COMPRESSION_LZ4. Saddly, CONFIG_RD_* is also used to
> choose the supported RD compression algorithms by the kernel and a user may
> want to suppport more than one.
> 
> This patch also reverses 3e4e0f0a8756dade3023d1f47d50fbced7749788
> ("initramfs: remove "compression mode" choice") restoring back the
> "compression mode" choice and includes the CONFIG_INITRAMFS_COMPRESSION_LZ4
> option which was never added.
> 
> As a result the following options are added or readed affecting the embedded
> initramfs compression:
> INITRAMFS_COMPRESSION_NONE Do no compression
> INITRAMFS_COMPRESSION_GZIP Compress using gzip
> INITRAMFS_COMPRESSION_BZIP2 Compress using bzip2
> INITRAMFS_COMPRESSION_LZMA Compress using lzma
> INITRAMFS_COMPRESSION_XZ Compress using xz
> INITRAMFS_COMPRESSION_LZO Compress using lzo
> INITRAMFS_COMPRESSION_LZ4 Compress using lz4
> 
> These depend on the corresponding CONFIG_RD_* option being set (except NONE
> which has no dependencies).

As you sent them, these patches would be merged with

	From: klondike <klondike@xxxxxxxxxxxxx>
	Signed-off-by: Francisco Blas Izquierdo Riera (klondike) <klondike@xxxxxxxxxxx>

Which is strange.  Different email addresses and "klondike" isn't a
real name.

So I'll rewrite the From: address to match the SOB address.

You can do this yourself by including an explicit From: line as the
first line of the changelog text.