1. 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
  2. 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
  3. 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
  4. 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
  5. 29 4月, 2008 1 次提交
  6. 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
  7. 07 2月, 2008 2 次提交
  8. 27 7月, 2007 1 次提交
  9. 12 2月, 2007 1 次提交
  10. 12 12月, 2006 1 次提交
  11. 08 12月, 2006 1 次提交
  12. 27 6月, 2006 1 次提交
  13. 16 5月, 2006 1 次提交
  14. 27 3月, 2006 1 次提交
  15. 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
  16. 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
  17. 13 9月, 2005 1 次提交
  18. 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