02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
18 Jul, 2015
1 commit
-
Without this we end up using the previous name of the compressor in the
loop in unpack_rootfs. For example we get errors like "compression
method gzip not configured" even when we have CONFIG_DECOMPRESS_GZIP
enabled.Signed-off-by: Aneesh Kumar K.V
Cc: "H. Peter Anvin"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
14 Dec, 2014
1 commit
-
Magic number of compress formats for kernel image is defined by two bytes.
These numbers are written in hexadecimal number, nevertheless magic
number for only gunzip is written in octal number. The formats should be
consistent for readability. Therefore, magic numbers for gunzip are also
defined by hexadecimal number.Signed-off-by: Haesung Kim
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
09 Aug, 2014
1 commit
-
Now with 64bit bzImage and kexec tools, we support ramdisk that size is
bigger than 2g, as we could put it above 4G.Found compressed initramfs image could not be decompressed properly. It
turns out that image length is int during decompress detection, and it
will become < 0 when length is more than 2G. Furthermore, during
decompressing len as int is used for inbuf count, that has problem too.Change len to long, that should be ok as on 32 bit platform long is
32bits.Tested with following compressed initramfs image as root with kexec.
gzip, bzip2, xz, lzma, lzop, lz4.
run time for populate_rootfs():
size name Nehalem-EX Westmere-EX Ivybridge-EX
9034400256 root_img : 26s 24s 30s
3561095057 root_img.lz4 : 28s 27s 27s
3459554629 root_img.lzo : 29s 29s 28s
3219399480 root_img.gz : 64s 62s 49s
2251594592 root_img.xz : 262s 260s 183s
2226366598 root_img.lzma: 386s 376s 277s
2901482513 root_img.bz2 : 635s 599sSigned-off-by: Yinghai Lu
Cc: "H. Peter Anvin"
Cc: Ingo Molnar
Cc: Rashika Kheria
Cc: Josh Triplett
Cc: Kyungsik Lee
Cc: P J P
Cc: Al Viro
Cc: Tetsuo Handa
Cc: "Daniel M. Weeks"
Cc: Alexandre Courbot
Cc: Jan Beulich
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
08 Apr, 2014
1 commit
-
This can greatly aid in narrowing down the real source of initramfs
problems such as failures related to the compression of the in-kernel
initramfs when an external initramfs is in use as well. Existing errors
are ambiguous as to which initramfs is a problem and why.[akpm@linux-foundation.org: use pr_debug()]
Signed-off-by: Daniel M. Weeks
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
10 Jul, 2013
1 commit
-
Add support for extracting LZ4-compressed kernel images, as well as
LZ4-compressed ramdisk images in the kernel boot process.Signed-off-by: Kyungsik Lee
Cc: "H. Peter Anvin"
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Russell King
Cc: Borislav Petkov
Cc: Florian Fainelli
Cc: Yann Collet
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
01 May, 2013
1 commit
-
Signed-off-by: Andi Kleen
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
06 Oct, 2012
1 commit
-
Fix the warning:
WARNING: vmlinux.o(.text+0x14cfd8): Section mismatch in reference from the variable compressed_formats to the function .init.text:gunzip()
The function compressed_formats() references
the function __init gunzip().
etc..Within decompress.c, compressed_formats[] needs 'a __initdata annotation',
because some of it's data members refer to functions which will be
unloaded after init.Consequently, its user decompress_method() will get the __init prefix.
Signed-off-by: Hein Tibosch
Cc: Albin Tonnerre
Cc: Phillip Lougher
Cc: "H. Peter Anvin"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
14 Jan, 2011
1 commit
-
This implements the API defined in which is
used for kernel, initramfs, and initrd decompression. This patch together
with the first patch is enough for XZ-compressed initramfs and initrd;
XZ-compressed kernel will need arch-specific changes.The buffering requirements described in decompress_unxz.c are stricter
than with gzip, so the relevant changes should be done to the
arch-specific code when adding support for XZ-compressed kernel.
Similarly, the heap size in arch-specific pre-boot code may need to be
increased (30 KiB is enough).The XZ decompressor needs memmove(), memeq() (memcmp() == 0), and
memzero() (memset(ptr, 0, size)), which aren't available in all
arch-specific pre-boot environments. I'm including simple versions in
decompress_unxz.c, but a cleaner solution would naturally be nicer.Signed-off-by: Lasse Collin
Cc: "H. Peter Anvin"
Cc: Alain Knaff
Cc: Albin Tonnerre
Cc: Phillip Lougher
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
12 Jan, 2010
1 commit
-
Signed-off-by: Albin Tonnerre
Tested-by: Wu Zhangjin
Acked-by: "H. Peter Anvin"
Cc: Ingo Molnar
Cc: Thomas Gleixner
Tested-by: Russell King
Acked-by: Russell King
Cc: Ralf Baechle
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
20 Feb, 2009
1 commit
-
Impact: Bugfix, avoids kernels which build but panic on boot
Fix a bug in decompress.c : only scanned until the first
non-configured compressor (with disastrous result especially if that
was gzip.)Signed-off-by: Alain Knaff
Signed-off-by: H. Peter Anvin
13 Jan, 2009
1 commit
-
Instead of failing to identify a compressed image with a decompressor
that we don't have compiled in, identify it and fail with a
comprehensible panic message.Signed-off-by: H. Peter Anvin
09 Jan, 2009
1 commit
-
Centralize the compression format detection to a common routine in the
lib directory, and use it for both initramfs and initrd.Signed-off-by: H. Peter Anvin