1. 15 1月, 2009 1 次提交
  2. 05 1月, 2009 1 次提交
    • A
      bzip2/lzma: x86 kernel compression support · ae03c499
      Alain Knaff 提交于
      Impact: Replaces x86 kernel decompressor with new code
      
      This is the third 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 bzip2 and lzma kernel compression for x86
      Signed-off-by: NAlain Knaff <alain@knaff.lu>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      ae03c499
  3. 23 10月, 2008 2 次提交
  4. 05 10月, 2008 1 次提交
  5. 23 7月, 2008 1 次提交
    • V
      x86: consolidate header guards · 77ef50a5
      Vegard Nossum 提交于
      This patch is the result of an automatic script that consolidates the
      format of all the headers in include/asm-x86/.
      
      The format:
      
      1. No leading underscore. Names with leading underscores are reserved.
      2. Pathname components are separated by two underscores. So we can
         distinguish between mm_types.h and mm/types.h.
      3. Everything except letters and numbers are turned into single
         underscores.
      Signed-off-by: NVegard Nossum <vegard.nossum@gmail.com>
      77ef50a5
  6. 20 4月, 2008 1 次提交
  7. 11 10月, 2007 1 次提交
  8. 13 7月, 2007 1 次提交
  9. 09 5月, 2007 1 次提交
  10. 06 1月, 2007 1 次提交
    • V
      [PATCH] i386: Restore CONFIG_PHYSICAL_START option · dd0ec16f
      Vivek Goyal 提交于
      o Relocatable bzImage support had got rid of CONFIG_PHYSICAL_START option
        thinking that now this option is not required as people can build a
        second kernel as relocatable and load it anywhere. So need of compiling
        the kernel for a custom address was gone. But Magnus uses vmlinux images
        for second kernel in Xen environment and he wants to continue to use
        it.
      
      o Restoring the CONFIG_PHYSICAL_START option for the time being. I think
        down the line we can get rid of it.
      Signed-off-by: NVivek Goyal <vgoyal@in.ibm.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      dd0ec16f
  11. 07 12月, 2006 1 次提交
    • V
      [PATCH] i386: Implement CONFIG_PHYSICAL_ALIGN · e69f202d
      Vivek Goyal 提交于
      o Now CONFIG_PHYSICAL_START is being replaced with CONFIG_PHYSICAL_ALIGN.
        Hardcoding the kernel physical start value creates a problem in relocatable
        kernel context due to boot loader limitations. For ex, if somebody
        compiles a relocatable kernel to be run from address 4MB, but this kernel
        will run from location 1MB as grub loads the kernel at physical address
        1MB. Kernel thinks that I am a relocatable kernel and I should run from
        the address I have been loaded at. So somebody wanting to run kernel
        from 4MB alignment location (for improved performance regions) can't do
        that.
      
      o Hence, Eric proposed that probably CONFIG_PHYSICAL_ALIGN will make
        more sense in relocatable kernel context. At run time kernel will move
        itself to a physical addr location which meets user specified alignment
        restrictions.
      Signed-off-by: NVivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      e69f202d
  12. 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