summaryrefslogtreecommitdiffstats
path: root/arch/x86/include/asm/kvm_page_track.h
diff options
context:
space:
mode:
authorMasahiro Yamada <masahiroy@kernel.org>2022-01-10 03:15:29 +0900
committerMasahiro Yamada <masahiroy@kernel.org>2022-01-14 02:57:43 +0900
commitc4d7f40b250c1a4d74ed259e84807f58032507b6 (patch)
tree5bbc3df1fd721ce81d9b4cbb0391f509e8231830 /arch/x86/include/asm/kvm_page_track.h
parent53e7b5dfb752399cd903ecb6e921dcaef57c8ea5 (diff)
downloadlinux-c4d7f40b250c1a4d74ed259e84807f58032507b6.tar.bz2
kbuild: add cmd_file_size
Some architectures support self-extracting kernel, which embeds the compressed vmlinux. It has 4 byte data at the end so the decompressor can know the vmlinux size beforehand. GZIP natively has it in the trailer, but for the other compression algorithms, the hand-crafted trailer is added. It is unneeded to generate such _corrupted_ compressed files because it is possible to pass the size data as a separate file. For example, the assembly code: .incbin "compressed-vmlinux-with-size-data" can be transformed to: .incbin "compressed-vmlinux" .incbin "size-data" My hope is, after some reworks of the decompressors, the macros cmd_{bzip2,lzma,lzo,lz4,xzkern,zstd22}_with_size will go away. This new macro, cmd_file_size, will be useful to generate a separate size-data file. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <n.schier@avm.de>
Diffstat (limited to 'arch/x86/include/asm/kvm_page_track.h')
0 files changed, 0 insertions, 0 deletions