31 Jul, 2020

1 commit

  • - Add support for a zstd compressed initramfs.

    - Add compression for compressing built-in initramfs with zstd.

    I have tested this patch by boot testing with buildroot and QEMU.
    Specifically, I booted the kernel with both a zstd and gzip compressed
    initramfs, both built into the kernel and separate. I ensured that the
    correct compression algorithm was used. I tested on arm, aarch64, i386,
    and x86_64.

    This patch has been tested in production on aarch64 and x86_64 devices.

    Additionally, I have performance measurements from internal use in
    production. On an aarch64 device we saw 19 second boot time improvement
    from switching from lzma to zstd (27 seconds to 8 seconds). On an x86_64
    device we saw a 9 second boot time reduction from switching from xz to
    zstd.

    Signed-off-by: Nick Terrell
    Signed-off-by: Ingo Molnar
    Tested-by: Sedat Dilek
    Reviewed-by: Kees Cook
    Link: https://lore.kernel.org/r/20200730190841.2071656-5-nickrterrell@gmail.com

    Nick Terrell
     

17 Mar, 2020

1 commit

  • Even though INITRAMFS_SOURCE kconfig option isn't set in most of
    defconfigs it is used (set) extensively by various build systems.
    Commit f26661e12765 ("initramfs: make initramfs compression choice
    non-optional") has changed default compression mode. Previously we
    compress initramfs using available compression algorithm. Now
    we don't use any compression at all by default.
    It significantly increases the image size in case of build system
    chooses embedded initramfs. Initially I faced with this issue while
    using buildroot.

    As of today it's not possible to set preferred compression mode
    in target defconfig as this option depends on INITRAMFS_SOURCE
    being set. Modification of all build systems either doesn't look
    like good option.

    Let's instead rewrite initramfs compression mode choices list
    the way that "INITRAMFS_COMPRESSION_NONE" will be the last option
    in the list. In that case it will be chosen only if all other
    options (which implements any compression) are not available.

    Signed-off-by: Eugeniy Paltsev
    Signed-off-by: Masahiro Yamada

    Eugeniy Paltsev
     

04 Feb, 2020

1 commit

  • Since commit ddd09bcc899f ("initramfs: make compression options not
    depend on INITRAMFS_SOURCE"), Kconfig asks the compression mode for
    the built-in initramfs regardless of INITRAMFS_SOURCE.

    It is technically simpler, but pointless from a UI perspective,
    Linus says [1].

    When INITRAMFS_SOURCE is empty, usr/Makefile creates a tiny default
    cpio, which is so small that nobody cares about the compression.

    This commit hides the Kconfig choice in that case. The default cpio
    is embedded without compression, which was the original behavior.

    [1]: https://lkml.org/lkml/2020/2/1/160

    Suggested-by: Linus Torvalds
    Signed-off-by: Masahiro Yamada
    Signed-off-by: Linus Torvalds

    Masahiro Yamada
     

15 Jan, 2020

1 commit

  • Currently, usr/gen_initramfs.sh takes care of all the use-cases:

    [1] generates a cpio file unless CONFIG_INITRAMFS_SOURCE points to
    a single cpio archive

    [2] If CONFIG_INITRAMFS_SOURCE is the path to a cpio archive,
    use it as-is.

    [3] Compress the cpio file according to CONFIG_INITRAMFS_COMPRESSION_*
    unless it is passed a compressed archive.

    To simplify the script, move [2] and [3] to usr/Makefile.

    If CONFIG_INITRAMFS_SOURCE is the path to a cpio archive, there is
    no need to run this shell script.

    For the cpio archive compression, you can re-use the rules from
    scripts/Makefile.lib .

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     

14 Jan, 2020

3 commits


15 Jul, 2019

2 commits


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

    Greg Kroah-Hartman
     

07 Jul, 2017

2 commits


03 Jun, 2017

1 commit

  • Commit db2aa7fd15e8 ("initramfs: allow again choice of the embedded
    initram compression algorithm") introduced the possibility to select the
    initramfs compression algorithm from Kconfig and while this is a nice
    feature it broke the use case described below.

    Here is what my build system does:

    - kernel is initially configured not to have an initramfs included

    - build the user space root file system

    - re-configure the kernel to have an initramfs included
    (CONFIG_INITRAMFS_SOURCE="/path/to/romfs") and set relevant
    CONFIG_INITRAMFS options, in my case, no compression option
    (CONFIG_INITRAMFS_COMPRESSION_NONE)

    - kernel is re-built with these options -> kernel+initramfs image is
    copied

    - kernel is re-built again without these options -> kernel image is
    copied

    Building a kernel without an initramfs means setting this option:

    CONFIG_INITRAMFS_SOURCE="" (and this one only)

    whereas building a kernel with an initramfs means setting these options:

    CONFIG_INITRAMFS_SOURCE="/home/fainelli/work/uclinux-rootfs/romfs /home/fainelli/work/uclinux-rootfs/misc/initramfs.dev"
    CONFIG_INITRAMFS_ROOT_UID=1000
    CONFIG_INITRAMFS_ROOT_GID=1000
    CONFIG_INITRAMFS_COMPRESSION_NONE=y
    CONFIG_INITRAMFS_COMPRESSION=""

    Commit db2aa7fd15e85 ("initramfs: allow again choice of the embedded
    initram compression algorithm") is problematic because
    CONFIG_INITRAMFS_COMPRESSION which is used to determine the
    initramfs_data.cpio extension/compression is a string, and due to how
    Kconfig works it will evaluate in order, how to assign it.

    Setting CONFIG_INITRAMFS_COMPRESSION_NONE with CONFIG_INITRAMFS_SOURCE=""
    cannot possibly work (because of the depends on INITRAMFS_SOURCE!=""
    imposed on CONFIG_INITRAMFS_COMPRESSION ) yet we still get
    CONFIG_INITRAMFS_COMPRESSION assigned to ".gz" because CONFIG_RD_GZIP=y
    is set in my kernel, even when there is no initramfs being built.

    So we basically end-up generating two initramfs_data.cpio* files, one
    without extension, and one with .gz. This causes usr/Makefile to track
    usr/initramfs_data.cpio.gz, and not usr/initramfs_data.cpio anymore,
    that is also largely problematic after 9e3596b0c6539e ("kbuild:
    initramfs cleanup, set target from Kconfig") because we used to track
    all possible initramfs_data files in the $(targets) variable before that
    commit.

    The end result is that the kernel with an initramfs clearly does not
    contain what we expect it to, it has a stale initramfs_data.cpio file
    built into it, and we keep re-generating an initramfs_data.cpio.gz file
    which is not the one that we want to include in the kernel image proper.

    The fix consists in hiding CONFIG_INITRAMFS_COMPRESSION when
    CONFIG_INITRAMFS_SOURCE="". This puts us back in a state to the
    pre-4.10 behavior where we can properly disable and re-enable initramfs
    within the same kernel .config file, and be in control of what
    CONFIG_INITRAMFS_COMPRESSION is set to.

    Fixes: db2aa7fd15e8 ("initramfs: allow again choice of the embedded initram compression algorithm")
    Fixes: 9e3596b0c653 ("kbuild: initramfs cleanup, set target from Kconfig")
    Link: http://lkml.kernel.org/r/20170521033337.6197-1-f.fainelli@gmail.com
    Signed-off-by: Florian Fainelli
    Acked-by: Nicholas Piggin
    Cc: P J P
    Cc: Paul Bolle
    Cc: Michal Marek
    Cc: Daniel Thompson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Florian Fainelli
     

09 May, 2017

1 commit

  • Many "embedded" architectures provide CMDLINE_FORCE to allow the kernel
    to override the command line provided by an inflexible bootloader.
    However there is currrently no way for the kernel to override the
    initramfs image provided by the bootloader meaning there are still ways
    for bootloaders to make things difficult for us.

    Fix this by introducing INITRAMFS_FORCE which can prevent the kernel
    from loading the bootloader supplied image.

    We use CMDLINE_FORCE (and its friend CMDLINE_EXTEND) to imply that the
    system has an inflexible bootloader. This allow us to avoid presenting
    this config option to users of systems where inflexible bootloaders
    aren't usually a problem.

    Link: http://lkml.kernel.org/r/20170217121940.30126-1-daniel.thompson@linaro.org
    Signed-off-by: Daniel Thompson
    Cc: Al Viro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Daniel Thompson
     

15 Dec, 2016

2 commits

  • Choosing the appropriate compression option when using an embedded
    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. 9ba4bcb645898d ("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 support more than one.

    This patch also reverts commit 3e4e0f0a875 ("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).

    This patch depends on the previous one (the previous version didn't) to
    simplify the way in which the algorithm is chosen and keep backwards
    compatibility with the behaviour introduced by 9ba4bcb645898
    ("initramfs: read CONFIG_RD_ variables for initramfs compression").

    Link: http://lkml.kernel.org/r/57EAD77B.7090607@klondike.es
    Signed-off-by: Francisco Blas Izquierdo Riera (klondike)
    Cc: P J P
    Cc: Paul Bolle
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Francisco Blas Izquierdo Riera (klondike)
     
  • Move the current builtin initram compression algorithm selection from
    the Makefile into the INITRAMFS_COMPRESSION variable. This makes
    deciding algorithm precedence easier and would allow for overrides if
    new algorithms want to be tested.

    Link: http://lkml.kernel.org/r/57EAD769.1090401@klondike.es
    Signed-off-by: Francisco Blas Izquierdo Riera (klondike)
    Cc: P J P
    Cc: Paul Bolle
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Francisco Blas Izquierdo Riera (klondike)
     

14 Dec, 2014

1 commit

  • The kernel has support for (nearly) every compression algorithm known to
    man, each to handle some particular microscopic niche.

    Unfortunately all of these always get compiled in if you want to support
    INITRDs, and can be only disabled when CONFIG_EXPERT is set.

    I don't see why I need to set EXPERT just to properly configure the initrd
    compression algorithms, and not always include every possible algorithm

    Usually the initrd is just compressed with gzip anyways, at least that's
    true on all distributions I use.

    Remove the dependencies for initrd compression on CONFIG_EXPERT.

    Make the various options just default y, which should be good enough to
    not break any previous configuration.

    Signed-off-by: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andi Kleen
     

07 Jun, 2014

1 commit

  • Commit 9ba4bcb64589 ("initramfs: read CONFIG_RD_ variables for initramfs
    compression") removed the users of the various INITRAMFS_COMPRESSION_*
    Kconfig symbols. So since v3.13 the entire "Built-in initramfs
    compression mode" choice is a set of knobs connected to nothing. The
    entire choice can safely be removed.

    Signed-off-by: Paul Bolle
    Cc: P J P
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul Bolle
     

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

    Kyungsik Lee
     

01 Jun, 2012

1 commit

  • There have been new compression algorithms added without updating nearby
    relevant descriptive text that refers to (a) the number of compression
    algorithms and (b) the most recent one. Fix these inconsistencies.

    Signed-off-by: Randy Dunlap
    Reported-by:
    Cc: Lasse Collin
    Cc: "H. Peter Anvin"
    Cc: Markus Trippelsdorf
    Cc: Alain Knaff
    Cc: Albin Tonnerre
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     

21 Jan, 2011

1 commit

  • The meaning of CONFIG_EMBEDDED has long since been obsoleted; the option
    is used to configure any non-standard kernel with a much larger scope than
    only small devices.

    This patch renames the option to CONFIG_EXPERT in init/Kconfig and fixes
    references to the option throughout the kernel. A new CONFIG_EMBEDDED
    option is added that automatically selects CONFIG_EXPERT when enabled and
    can be used in the future to isolate options that should only be
    considered for embedded systems (RISC architectures, SLOB, etc).

    Calling the option "EXPERT" more accurately represents its intention: only
    expert users who understand the impact of the configuration changes they
    are making should enable it.

    Reviewed-by: Ingo Molnar
    Acked-by: David Woodhouse
    Signed-off-by: David Rientjes
    Cc: Greg KH
    Cc: "David S. Miller"
    Cc: Jens Axboe
    Cc: Arnd Bergmann
    Cc: Robin Holt
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Rientjes
     

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

    Lasse Collin
     

23 Aug, 2010

1 commit


12 Jan, 2010

1 commit


01 Apr, 2009

1 commit


29 Mar, 2009

4 commits


20 Feb, 2009

1 commit

  • Impact: Avoids silent environment dependency

    Make builtin initramfs compression an explicit configurable. The
    previous version would pick a compression based on the binaries which
    were installed on the system, which could lead to unexpected results.
    It is now explicitly configured, and not having the appropriate
    binaries installed on the build host is simply an error.

    Signed-off-by: Alain Knaff
    Signed-off-by: H. Peter Anvin

    Alain Knaff
     

07 Jan, 2009

1 commit


03 May, 2007

1 commit


11 Aug, 2005

1 commit