Commit graph

6 commits

Author SHA1 Message Date
Richard Purdie
4f3865fb57 [PATCH] zlib_inflate: Upgrade library code to a recent version
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: Richard Purdie <rpurdie@rpsys.net>
Acked-by: Joern Engel <joern@wh.fh-wedel.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-22 15:05:58 -07:00
Adrian Bunk
87c2ce3b93 [PATCH] lib/zlib*: cleanups
This patch contains the following possible cleanups:
- #if 0 the following unused functions:
  - zlib_deflate/deflate.c: zlib_deflateSetDictionary
  - zlib_deflate/deflate.c: zlib_deflateParams
  - zlib_deflate/deflate.c: zlib_deflateCopy
  - zlib_inflate/infblock.c: zlib_inflate_set_dictionary
  - zlib_inflate/infblock.c: zlib_inflate_blocks_sync_point
  - zlib_inflate/inflate_sync.c: zlib_inflateSync
  - zlib_inflate/inflate_sync.c: zlib_inflateSyncPoint
- remove the following unneeded EXPORT_SYMBOL's:
  - zlib_deflate/deflate_syms.c: zlib_deflateCopy
  - zlib_deflate/deflate_syms.c: zlib_deflateParams
  - zlib_inflate/inflate_syms.c: zlib_inflateSync
  - zlib_inflate/inflate_syms.c: zlib_inflateSyncPoint

Signed-off-by: Adrian Bunk <bunk@stusta.de>
Cc: Matt Mackall <mpm@selenic.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-10 08:01:57 -08:00
Olaf Hering
27ac801a2e [PATCH] ppc64 boot: remove include from lib/zlib_inflate/inflate.c
There is no need to include module.h in inflate.c

Signed-off-by: Olaf Hering <olh@suse.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Anton Blanchard <anton@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-10-29 15:03:00 +10:00
Linus Torvalds
c231c7db30 Revert unnecessary zlib_inflate/inftrees.c fix
It turns out that empty distance code tables are not an error, and that
a compressed block with only literals can validly have an empty table
and should not be flagged as a data error.

Some old versions of gzip had problems with this case, but it does not
affect the zlib code in the kernel.

Analysis and explanations thanks to Sergey Vlasov <vsu@altlinux.ru>

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-17 13:07:28 -07:00
Tim Yamin
4aad724d3e [PATCH] Update in-kernel zlib routines
These bugs have been fixed in the standard zlib for a while.

See for example

 a) http://sources.redhat.com/ml/bug-gnu-utils/1999-06/msg00183.html
 b) http://bugs.gentoo.org/show_bug.cgi?id=94584

Signed-off-by: Tim Yamin <plasmaroo@gentoo.org>
Signed-off-by: Tavis Ormandy <taviso@gentoo.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-05 16:23:21 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00