lkml.org 
[lkml]   [2016]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: About support XZ-compressed kernel on x86
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

\
 
 \ /
  Last update: 2016-02-13 20:21    [W:2.548 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site