1. 23 6月, 2006 1 次提交
    • R
      [PATCH] zlib_inflate: Upgrade library code to a recent version · 4f3865fb
      Richard Purdie 提交于
      Upgrade the zlib_inflate implementation in the kernel from a patched
      version 1.1.3/4 to a patched 1.2.3.
      
      The code in the kernel is about seven years old and I noticed that the
      external zlib library's inflate performance was significantly faster (~50%)
      than the code in the kernel on ARM (and faster again on x86_32).
      
      For comparison the newer deflate code is 20% slower on ARM and 50% slower
      on x86_32 but gives an approx 1% compression ratio improvement.  I don't
      consider this to be an improvement for kernel use so have no plans to
      change the zlib_deflate code.
      
      Various changes have been made to the zlib code in the kernel, the most
      significant being the extra functions/flush option used by ppp_deflate.
      This update reimplements the features PPP needs to ensure it continues to
      work.
      
      This code has been tested on ARM under both JFFS2 (with zlib compression
      enabled) and ppp_deflate and on x86_32.  JFFS2 sees an approx.  10% real
      world file read speed improvement.
      
      This patch also removes ZLIB_VERSION as it no longer has a correct value.
      We don't need version checks anyway as the kernel's module handling will
      take care of that for us.  This removal is also more in keeping with the
      zlib author's wishes (http://www.zlib.net/zlib_faq.html#faq24) and I've
      added something to the zlib.h header to note its a modified version.
      Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>
      Acked-by: NJoern Engel <joern@wh.fh-wedel.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4f3865fb
  2. 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