This commit cleans up the comments and fixes the code alignment using Xen
coding style. This is done to make the code more legible before refactoring.
Signed-off-by: Daniel P. Smith
---
xen/common/gzip/gunzip.c | 14 +-
xen/common/gzip/inflate.c | 787 +++---
2 files changed, 406 insertions(+), 395 deletions(-)
diff --git a/xen/common/gzip/gunzip.c b/xen/common/gzip/gunzip.c
index 53cee9ee178a..d07c451cd875 100644
--- a/xen/common/gzip/gunzip.c
+++ b/xen/common/gzip/gunzip.c
@@ -54,11 +54,10 @@ static __init void error(const char *x)
static __init int fill_inbuf(void)
{
-error("ran out of input data");
-return 0;
+error("ran out of input data");
+return 0;
}
-
#include "inflate.c"
static __init void flush_window(void)
@@ -122,3 +121,12 @@ __init int perform_gunzip(char *output, char *image,
unsigned long image_len)
return rc;
}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/gzip/inflate.c b/xen/common/gzip/inflate.c
index a03903f73116..220d2ff4d9d9 100644
--- a/xen/common/gzip/inflate.c
+++ b/xen/common/gzip/inflate.c
@@ -1,11 +1,13 @@
#define DEBG(x)
#define DEBG1(x)
-/* inflate.c -- Not copyrighted 1992 by Mark Adler
- version c10p1, 10 January 1993 */
+/*
+ * inflate.c -- Not copyrighted 1992 by Mark Adler
+ * version c10p1, 10 January 1993
+ */
-/*
+/*
* Adapted for booting Linux by Hannu Savolainen 1993
- * based on gzip-1.0.3
+ * based on gzip-1.0.3
*
* Nicolas Pitre , 1999/04/14 :
* Little mods for all variable to reside either into rodata or bss segments
@@ -15,92 +17,91 @@
*/
/*
- Inflate deflated (PKZIP's method 8 compressed) data. The compression
- method searches for as much of the current string of bytes (up to a
- length of 258) in the previous 32 K bytes. If it doesn't find any
- matches (of at least length 3), it codes the next byte. Otherwise, it
- codes the length of the matched string and its distance backwards from
- the current position. There is a single Huffman code that codes both
- single bytes (called "literals") and match lengths. A second Huffman
- code codes the distance information, which follows a length code. Each
- length or distance code actually represents a base value and a number
- of "extra" (sometimes zero) bits to get to add to the base value. At
- the end of each deflated block is a special end-of-block (EOB) literal/
- length code. The decoding process is basically: get a literal/length
- code; if EOB then done; if a literal, emit the decoded byte; if a
- length then get the distance and emit the referred-to bytes from the
- sliding window of previously emitted data.
-
- There are (currently) three kinds of inflate blocks: stored, fixed, and
- dynamic. The compressor deals with some chunk of data at a time, and
- decides which method to use on a chunk-by-chunk basis. A chunk might
- typically be 32 K or 64 K. If the chunk is incompressible, then the
- "stored" method is used. In this case, the bytes are simply stored as
- is, eight bits per byte, with none of the above coding. The bytes are
- preceded by a count, since there is no longer an EOB code.
-
- If the data is compressible, then either the fixed or dynamic methods
- are used. In the dynamic method, the compressed data is preceded by
- an encoding of the literal/length and distance Huffman codes that are
- to be used to decode this block. The representation is itself Huffman
- coded, and so is preceded by a description of that code. These code
- descriptions take up a little space, and so for small blocks, there is
- a predefined set of codes, called the fixed codes. The fixed method is
- used if the block codes up smaller that way (usually for quite small
- chunks), otherwise the dynamic method is used. In the latter case, the
- codes are customized to the probabilities in the current block, and so
- can code it much better than the pre-determined fixed codes.
-
- The Huffman codes themselves are decoded using a multi-level table
- lookup, in order to maximize the speed of decoding plus the speed of
- building the decoding tables. See the comments below that precede the
- lbits and dbits tuning parameters.
+ * Inflate deflated (PKZIP's method 8 compressed) data. The compression
+ * method searches for as much of the current string of bytes (up to a
+ * length of 258) in the previous 32 K bytes. If it doesn't find any
+ * matches (of at least length 3), it codes the next byte. Otherwise, it
+ * codes the length of the matched string and its distance backwards from
+ * the current position. There is a single Huffman code that codes both
+ * single bytes (called "literals") and match lengths. A second Huffman
+ * code codes the distance information, which follows a length code. Each
+ * length or distance
