Re: About support XZ-compressed kernel on x86

[Lasse Collin <lasse.collin@tukaani.org>]

On 2016-02-12 Baoquan He wrote:
> Now I have a question about the commit from you:
> 
> commit 303148045aac34b70db722a54e5ad94a3a6625c6
> Author: Lasse Collin <lasse.collin@tukaani.org>
> Date:   Wed Jan 12 17:01:24 2011 -0800
> 
>     x86: support XZ-compressed kernel
> 
> 
> In this commit for adding support of XZ-compressed kernel on x86, you
> add extra 32K to the extract_offset. In commit log you said this is
> because "The XZ decompressor needs around 30 KiB of heap, so the heap
> size is increased to 32 KiB on both x86-32 and x86-64." With my
> understanding decompression is done in decompression stage and it uses
> boot_heap in arch/x86/boot/compressed/head_64.S, and boot_heap is
> assigned to free_mem_ptr which is used for decompression heap malloc.
> During this decompressio stage it's still in copied ZO space, why did
> you add extra 32K space to extract_offset?  If you want to increase
> the decompression heap space shouldn't you decrease the
> extract_offset? Do I misunderstand anything or miss things?

The reason to increase the heap size in arch/x86/include/asm/boot.h is
unrelated to the reason why the offset was changed in
arch/x86/boot/compressed/mkpiggy.c.

The long comment in arch/x86/boot/compressed/misc.c explains the need
for the offset for gzip/Deflate. A similar comment in
lib/decompress_unxz.c explains it for XZ/LZMA2.

Smaller safety-margins can work in practice since the calculated
margins are for the worst case. I'm not even sure if such calculations
have been done for the other decompressors in Linux.

-- 
Lasse Collin  |  IRC: Larhzu @ IRCnet & Freenode