1. 19 1月, 2013 1 次提交
    • T
      init, block: try to load default elevator module early during boot · bb813f4c
      Tejun Heo 提交于
      This patch adds default module loading and uses it to load the default
      block elevator.  During boot, it's called right after initramfs or
      initrd is made available and right before control is passed to
      userland.  This ensures that as long as the modules are available in
      the usual places in initramfs, initrd or the root filesystem, the
      default modules are loaded as soon as possible.
      
      This will replace the on-demand elevator module loading from elevator
      init path.
      
      v2: Fixed build breakage when !CONFIG_BLOCK.  Reported by kbuild test
          robot.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Alex Riesen <raa.lkml@gmail.com>
      Cc: Fengguang We <fengguang.wu@intel.com>
      bb813f4c
  2. 01 6月, 2012 1 次提交
  3. 04 1月, 2012 1 次提交
  4. 27 10月, 2010 1 次提交
  5. 29 9月, 2010 1 次提交
    • H
      initramfs: fix initramfs size calculation · ffe8018c
      Hendrik Brueckner 提交于
      The size of a built-in initramfs is calculated in init/initramfs.c by
      "__initramfs_end - __initramfs_start".  Those symbols are defined in the
      linker script include/asm-generic/vmlinux.lds.h:
      
      #define INIT_RAM_FS                                                     \
              . = ALIGN(PAGE_SIZE);                                           \
              VMLINUX_SYMBOL(__initramfs_start) = .;                          \
              *(.init.ramfs)                                                  \
              VMLINUX_SYMBOL(__initramfs_end) = .;
      
      If the initramfs file has an odd number of bytes, the "__initramfs_end"
      symbol points to an odd address, for example, the symbols in the
      System.map might look like:
      
          0000000000572000 T __initramfs_start
          00000000005bcd05 T __initramfs_end	  <-- odd address
      
      At least on s390 this causes a problem:
      
      Certain s390 instructions, especially instructions for loading addresses
      (larl) or branch addresses must be on even addresses.  The compiler loads
      the symbol addresses with the "larl" instruction.  This instruction sets
      the last bit to 0 and, therefore, for odd size files, the calculated size
      is one byte less than it should be:
      
          0000000000540a9c <populate_rootfs>:
            540a9c:     eb cf f0 78 00 24       stmg    %r12,%r15,120(%r15),
            540aa2:     c0 10 00 01 8a af       larl    %r1,572000 <__initramfs_start>
            540aa8:     c0 c0 00 03 e1 2e       larl    %r12,5bcd04 <initramfs_end>
                                                        (Instead of  5bcd05)
            ...
            540abe:     1b c1                   sr      %r12,%r1
      
      To fix the problem, this patch introduces the global variable
      __initramfs_size, which is calculated in the "usr/initramfs_data.S" file.
      The populate_rootfs() function can then use the start marker of the
      .init.ramfs section and the value of __initramfs_size for loading the
      initramfs.  Because the start marker and size is sufficient, the
      __initramfs_end symbol is no longer needed and is removed.
      Signed-off-by: NMichael Holzheu <holzheu@linux.vnet.ibm.com>
      Signed-off-by: NHendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Reviewed-by: NWANG Cong <xiyou.wangcong@gmail.com>
      Acked-by: NMichal Marek <mmarek@suse.cz>
      Acked-by: N"H. Peter Anvin" <hpa@zytor.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      ffe8018c
  6. 25 4月, 2010 1 次提交
  7. 07 3月, 2010 1 次提交
  8. 16 12月, 2009 1 次提交
  9. 07 5月, 2009 1 次提交
  10. 14 4月, 2009 2 次提交
  11. 03 4月, 2009 1 次提交
  12. 29 3月, 2009 1 次提交
  13. 15 1月, 2009 1 次提交
    • H
      init: make initrd/initramfs decompression failure a KERN_EMERG event · 73310a16
      H. Peter Anvin 提交于
      Impact: More consistent behaviour, avoid policy in the kernel
      
      Upgrade/downgrade initrd/initramfs decompression failure from
      inconsistently a panic or a KERN_ALERT message to a KERN_EMERG event.
      It is, however, possible do design a system which can recover from
      this (using the kernel builtin code and/or the internal initramfs),
      which means this is policy, not a technical necessity.
      
      A good way to handle this would be to have a panic-level=X option, to
      force a panic on a printk above a certain level.  That is a separate
      patch, however.
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      73310a16
  14. 13 1月, 2009 1 次提交
  15. 10 1月, 2009 1 次提交
    • I
      bzip2/lzma: make flush_buffer() unconditional · 736f9323
      Ingo Molnar 提交于
      Impact: build fix
      
      flush_buffer() is used unconditionally:
      
        init/initramfs.c:456: error: 'flush_buffer' undeclared (first use in this function)
        init/initramfs.c:456: error: (Each undeclared identifier is reported only once
        init/initramfs.c:456: error: for each function it appears in.)
      
      So remove the decompressor #ifdefs from around it.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      736f9323
  16. 09 1月, 2009 1 次提交
  17. 08 1月, 2009 1 次提交
    • D
      NOMMU: Support XIP on initramfs · cb6ff208
      David Howells 提交于
      Support XIP on files unpacked from the initramfs image on NOMMU systems.  This
      simply requires the length of the file to be preset so that the ramfs fs can
      attempt to garner sufficient contiguous storage to store the file (NOMMU mmap
      can only map contiguous RAM).
      
      All the other bits to do XIP on initramfs files are present:
      
       (1) ramfs's truncate attempts to allocate a contiguous run of pages when a
           file is truncated upwards from nothing.
      
       (2) ramfs sets BDI on its files to indicate direct mapping is possible, and
           that its files can be mapped for read, write and exec.
      
       (3) NOMMU mmap() will use the above bits to determine that it can do XIP.
           Possibly this needs better controls, because it will _always_ try and do
           XIP.
      
      One disadvantage of this very simplistic approach is that sufficient space
      will be allocated to store the whole file, and not just the bit that would be
      XIP'd.  To deal with this, though, the initramfs unpacker would have to be
      able to parse the file contents.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Acked-by: NPaul Mundt <lethal@linux-sh.org>
      cb6ff208
  18. 07 1月, 2009 1 次提交
    • A
      bzip2/lzma: fix built-in initramfs vs CONFIG_RD_GZIP · a26ee60f
      Alain Knaff 提交于
      Impact: Resolves build failures in some configurations
      
      Makes it possible to disable CONFIG_RD_GZIP . In that case, the
      built-in initramfs will be compressed by whatever compressor is
      available (bzip2 or lzma) or left uncompressed if none is available.
      
      It also removes a couple of warnings which occur when no ramdisk
      compression at all is chosen.
      
      It also restores the select ZLIB_INFLATE in drivers/block/Kconfig
      which somehow came missing. This is needed to activate compilation of
      the stuff in zlib_deflate.
      Signed-off-by: NAlain Knaff <alain@knaff.lu>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      a26ee60f
  19. 05 1月, 2009 1 次提交
    • A
      bzip2/lzma: config and initramfs support for bzip2/lzma decompression · 30d65dbf
      Alain Knaff 提交于
      Impact: New code for initramfs decompression, new features
      
      This is the second part of the bzip2/lzma patch
      
      The bzip patch is based on an idea by Christian Ludwig, includes support for
      compressing the kernel with bzip2 or lzma rather than gzip. Both
      compressors give smaller sizes than gzip.  Lzma's decompresses faster
      than bzip2.
      
      It also supports ramdisks and initramfs' compressed using these two
      compressors.
      
      The functionality has been successfully used for a couple of years by
      the udpcast project
      
      This version applies to "tip" kernel 2.6.28
      
      This part contains:
      - support for new compressions (bzip2 and lzma) in initramfs and
      old-style ramdisk
      - config dialog for kernel compression (but new kernel compressions
      not yet supported)
      Signed-off-by: NAlain Knaff <alain@knaff.lu>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      30d65dbf
  20. 17 10月, 2008 1 次提交
    • N
      initramfs: add option to preserve mtime from initramfs cpio images · 889d51a1
      Nye Liu 提交于
      When unpacking the cpio into the initramfs, mtimes are not preserved by
      default.  This patch adds an INITRAMFS_PRESERVE_MTIME option that allows
      mtimes stored in the cpio image to be used when constructing the
      initramfs.
      
      For embedded applications that run exclusively out of the initramfs, this
      is invaluable:
      
      When building embedded application initramfs images, its nice to know when
      the files were actually created during the build process - that makes it
      easier to see what files were modified when so we can compare the files
      that are being used on the image with the files used during the build
      process.  This might help (for example) to determine if the target system
      has all the updated files you expect to see w/o having to check MD5s etc.
      
      In our environment, the whole system runs off the initramfs partition, and
      seeing the modified times of the shared libraries (for example) helps us
      find bugs that may have been introduced by the build system incorrectly
      propogating outdated shared libraries into the image.
      
      Similarly, many of the initializion/configuration files in /etc might be
      dynamically built by the build system, and knowing when they were modified
      helps us sanity check whether the target system has the "latest" files
      etc.
      
      Finally, we might use last modified times to determine whether a hot fix
      should be applied or not to the running ramfs.
      Signed-off-by: NNye Liu <nyet@nyet.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      889d51a1
  21. 26 7月, 2008 1 次提交
    • T
      inflate: refactor inflate malloc code · 2d6ffcca
      Thomas Petazzoni 提交于
      Inflate requires some dynamic memory allocation very early in the boot
      process and this is provided with a set of four functions:
      malloc/free/gzip_mark/gzip_release.
      
      The old inflate code used a mark/release strategy rather than implement
      free.  This new version instead keeps a count on the number of outstanding
      allocations and when it hits zero, it resets the malloc arena.
      
      This allows removing all the mark and release implementations and unifying
      all the malloc/free implementations.
      
      The architecture-dependent code must define two addresses:
       - free_mem_ptr, the address of the beginning of the area in which
         allocations should be made
       - free_mem_end_ptr, the address of the end of the area in which
         allocations should be made. If set to 0, then no check is made on
         the number of allocations, it just grows as much as needed
      
      The architecture-dependent code can also provide an arch_decomp_wdog()
      function call.  This function will be called several times during the
      decompression process, and allow to notify the watchdog that the system is
      still running.  If an architecture provides such a call, then it must
      define ARCH_HAS_DECOMP_WDOG so that the generic inflate code calls
      arch_decomp_wdog().
      
      Work initially done by Matt Mackall, updated to a recent version of the
      kernel and improved by me.
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Mikael Starvik <mikael.starvik@axis.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Acked-by: NPaul Mundt <lethal@linux-sh.org>
      Acked-by: NYoshinori Sato <ysato@users.sourceforge.jp>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2d6ffcca
  22. 29 4月, 2008 1 次提交
  23. 16 3月, 2008 1 次提交
    • L
      ACPI: Remove ACPI_CUSTOM_DSDT_INITRD option · 9a9e0d68
      Linus Torvalds 提交于
      This essentially reverts commit 71fc47a9
      ("ACPI: basic initramfs DSDT override support"), because the code simply
      isn't ready.
      
      It did ugly things to the init sequence to populate the rootfs image
      early, but that just ended up showing other problems with the whole
      approach.  The fact is, the VFS layer simply isn't initialized this
      early, and the relevant ACPI code should either run much later, or this
      shouldn't be done at all.
      
      For 2.6.25, we'll just pick the latter option.  We can revisit this
      concept later if necessary.
      
      Cc: Dave Hansen <haveblue@us.ibm.com>
      Cc: Tilman Schmidt <tilman@imap.cc>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Thomas Renninger <trenn@suse.de>
      Cc: Eric Piel <eric.piel@tremplin-utc.net>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Markus Gaugusch <dsdt@gaugusch.at>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9a9e0d68
  24. 07 2月, 2008 2 次提交
  25. 27 7月, 2007 1 次提交
  26. 12 2月, 2007 1 次提交
  27. 12 12月, 2006 1 次提交
  28. 08 12月, 2006 1 次提交
  29. 27 6月, 2006 1 次提交
  30. 16 5月, 2006 1 次提交
  31. 27 3月, 2006 1 次提交
  32. 26 3月, 2006 1 次提交
    • Z
      [PATCH] BLK_DEV_INITRD: do not require BLK_DEV_RAM=y · 340e48e6
      Zdenek Pavlas 提交于
      Initramfs initrd images do not need a ramdisk device, so remove this
      restriction in Kconfig.  BLK_DEV_RAM=n saves about 13k on i386.  Also
      without ramdisk device there's no need for "dry run", so initramfs unpacks
      much faster.
      
      People using cramfs, squashfs, or gzipped ext2/minix initrd images are
      probably smart enough not to turn off ramdisk support by accident.
      
      Cc: Al Viro <viro@ftp.linux.org.uk>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      340e48e6
  33. 11 2月, 2006 1 次提交
    • H
      [PATCH] kexec: fix in free initrd when overlapped with crashkernel region · 9c15e852
      Haren Myneni 提交于
      It is possible that the reserved crashkernel region can be overlapped with
      initrd since the bootloader sets the initrd location.  When the initrd
      region is freed, the second kernel memory will not be contiguous.  The
      Kexec_load can cause an oops since there is no contiguous memory to write
      the second kernel or this memory could be used in the first kernel itself
      and may not be part of the dump.  For example, on powerpc, the initrd is
      located at 36MB and the crashkernel starts at 32MB.  The kexec_load caused
      panic since writing into non-allocated memory (after 36MB).  We could see
      the similar issue even on other archs.
      
      One possibility is to move the initrd outside of crashkernel region.  But,
      the initrd region will be freed anyway before the system is up.  This patch
      fixes this issue and frees only regions that are not part of crashkernel
      memory in case overlaps.
      Signed-off-by: NHaren Myneni <haren@us.ibm.com>
      Acked-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Vivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9c15e852
  34. 13 9月, 2005 1 次提交
  35. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4