1. 14 1月, 2011 1 次提交
    • L
      decompressors: add boot-time XZ support · 3ebe1243
      Lasse Collin 提交于
      This implements the API defined in <linux/decompress/generic.h> 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: NLasse Collin <lasse.collin@tukaani.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Alain Knaff <alain@knaff.lu>
      Cc: Albin Tonnerre <albin.tonnerre@free-electrons.com>
      Cc: Phillip Lougher <phillip@lougher.demon.co.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3ebe1243
  2. 29 9月, 2010 1 次提交
  3. 28 5月, 2010 1 次提交
  4. 20 9月, 2009 1 次提交
  5. 01 4月, 2009 1 次提交
  6. 20 2月, 2009 1 次提交
  7. 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
  8. 12 2月, 2007 1 次提交
    • J
      [PATCH] disable init/initramfs.c · c33df4ea
      Jean-Paul Saman 提交于
      The file init/initramfs.c is always compiled and linked in the kernel
      vmlinux even when BLK_DEV_RAM and BLK_DEV_INITRD are disabled and the
      system isn't using any form of an initramfs or initrd.  In this situation
      the code is only used to unpack a (static) default initial rootfilesystem.
      The current init/initramfs.c code.  usr/initramfs_data.o compiles to a size
      of ~15 kbytes.  Disabling BLK_DEV_RAM and BLK_DEV_INTRD shrinks the kernel
      code size with ~60 Kbytes.
      
      This patch avoids compiling in the code and data for initramfs support if
      CONFIG_BLK_DEV_INITRD is not defined.  Instead of the initramfs code and
      data it uses a small routine in init/noinitramfs.c to setup an initial
      static default environment for mounting a rootfilesystem later on in the
      kernel initialisation process.  The new code is: 164 bytes of size.
      
      The patch is separated in two parts:
      1) doesn't compile initramfs code when CONFIG_BLK_DEV_INITRD is not set
      2) changing all plaforms vmlinux.lds.S files to not reserve an area of
      PAGE_SIZE when CONFIG_BLK_DEV_INITRD is not set.
      
      [deweerdt@free.fr: warning fix]
      Signed-off-by: NJean-Paul Saman <jean-paul.saman@nxp.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NFrederik Deweerdt <frederik.deweerdt@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c33df4ea
  9. 26 11月, 2006 1 次提交
  10. 25 9月, 2006 1 次提交
  11. 08 8月, 2006 1 次提交
    • S
      kbuild: do not try to build content of initramfs · 58a2f7d8
      Sam Ravnborg 提交于
      When a file supplied via CONFIG_INITRAMFS pointed to a file
      for which kbuild had a rule to compile it (foo.c => foo.o)
      then kbuild would compile the file before adding the
      file to the initramfs.
      
      Teach make that files included in initramfs shall not be updated by adding
      an 'empty command'. (See "Using Empty Commands" in info make).
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      58a2f7d8
  12. 10 6月, 2006 1 次提交
  13. 11 4月, 2006 1 次提交
    • S
      kbuild: rebuild initramfs if content of initramfs changes · d39a206b
      Sam Ravnborg 提交于
      initramfs.cpio.gz being build in usr/ and included in the
      kernel was not rebuild when the included files changed.
      
      To fix this the following was done:
      - let gen_initramfs.sh generate a list of files and directories included
        in the initramfs
      - gen_initramfs generate the gzipped cpio archive so we could simplify
        the kbuild file (Makefile)
      - utilising the kbuild infrastructure so when uid/gid root mapping changes
        the initramfs will be rebuild
      
      With this change we have a much more robust initramfs generation.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      d39a206b
  14. 26 7月, 2005 1 次提交
    • S
      kbuild: introduce Kbuild.include · 8ec4b4ff
      Sam Ravnborg 提交于
      Kbuild.include is a placeholder for definitions originally present in
      both the top-level Makefile and scripts/Makefile.build.
      There were a slight difference in the filechk definition, so the most videly
      used version was kept and usr/Makefile was adopted for this syntax.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      ---
      8ec4b4ff
  15. 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