aboutsummaryrefslogtreecommitdiff
path: root/lib/zlib_inflate
AgeCommit message (Collapse)Author
2007-10-10[ZLIB]: Move bnx2 driver gzip unpacker into zlib.Denys Vlasenko
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com> Acked-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-05-07Fix ppp_deflate issues with recent zlib_inflate changesRichard Purdie
The last zlib_inflate update broke certain corner cases for ppp_deflate decompression handling. This patch fixes some logic to make things work properly again. Users other than ppp_deflate (the only Z_PACKET_FLUSH user) should be unaffected. Fixes bug 8405 (confirmed by Stefan) Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Cc: Stefan Wenk <stefan.wenk@gmx.at> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2006-07-31[PATCH] Fix ppc32 zImage inflatePeter Korsgaard
The recent zlib update (commit 4f3865fb57a04db7cca068fed1c15badc064a302) broke ppc32 zImage decompression as it tries to decompress to address zero and the updated zlib_inflate checks that strm->next_out isn't a null pointer. This little patch fixes it. [rpurdie@rpsys.net: add comment] Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> Acked-by: Tom Rini <trini@kernel.crashing.org> Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-27[PATCH] zlib inflate: fix function definitionsRandy Dunlap
Fix function definitions to be ANSI-compliant: lib/zlib_inflate/inffast.c:68:1: warning: non-ANSI definition of function 'inflate_fast' lib/zlib_inflate/inftrees.c:33:1: warning: non-ANSI definition of function 'zlib_inflate_table' Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26move acknowledgment for Mark Adler to CREDITSAdrian Bunk
The place in the documentation of the Linux kernel to acknowledge contributions is the CREDITS file. Give Mark Adler an entry there instead of including a string in the kernel image. Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-06-22[PATCH] zlib_inflate: Upgrade library code to a recent versionRichard 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: 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-01-10[PATCH] lib/zlib*: cleanupsAdrian Bunk
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>
2005-10-29[PATCH] ppc64 boot: remove include from lib/zlib_inflate/inflate.cOlaf Hering
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-08-17Revert unnecessary zlib_inflate/inftrees.c fixLinus Torvalds
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-05[PATCH] Update in-kernel zlib routinesTim Yamin
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-04-16Linux-2.6.12-rc2Linus 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!