Xen-Devel Archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
To: xen-devel@lists.xenproject.org
Cc: Jason Andryuk <jason.andryuk@amd.com>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v3 0/8] Clean up of gzip decompressor
Date: Wed, 24 Apr 2024 12:34:14 -0400	[thread overview]
Message-ID: <20240424163422.23276-1-dpsmith@apertussolutions.com> (raw)

An issue ran into by hyperlaunch was the need to use the gzip decompressor
multiple times. The current implementation fails when reused due to tainting of
decompressor state from a previous usage. This series seeks to colocate the
gzip unit files under a single directory similar to the other decompression
algorithms.  To enable the refactoring of the state tracking, the code is then
cleaned up in line with Xen coding style.

Changes in v3:
- patch "xen/gzip: Drop huffman code table tracking" was merged
- patch "xen/gzip: Remove custom memory allocator" was merged
- patch "xen/gzip: Drop unused define checks" was merged
- move of the decompressor state into struct was broken up to ease review
- expanded macros that were either only used once or obsfucated the logic
- adjusted variable types as needed to be more appropriate for their usage

Changes in v2:
- patch "xen/gzip: Colocate gunzip code files" was merged
- dropped ifdef chunks that are never enabled
- addressed formatting changes missed in v1
- replaced custom memory allocator with xalloc_bytes()
- renamed gzip_data to gzip_state
- moved gzip_state to being dynamically allocated
- changed crc table to the explicit size of uint32_t 
- instead of moving huffman tracking into state, dropped altogether


Daniel P. Smith (8):
  gzip: clean up comments and fix code alignment
  gzip: refactor and expand macros
  gzip: refactor the gunzip window into common state
  gzip: move window pointer into gunzip state
  gzip: move input buffer handling into gunzip state
  gzip: move output buffer into gunzip state
  gzip: move bitbuffer into gunzip state
  gzip: move crc state into gunzip state

 xen/common/gzip/gunzip.c  |  84 ++--
 xen/common/gzip/inflate.c | 948 +++++++++++++++++++-------------------
 2 files changed, 516 insertions(+), 516 deletions(-)

-- 
2.30.2



             reply	other threads:[~2024-04-24 16:34 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-24 16:34 Daniel P. Smith [this message]
2024-04-24 16:34 ` [PATCH v3 1/8] gzip: clean up comments and fix code alignment Daniel P. Smith
2024-04-25 18:31   ` Andrew Cooper
2024-04-24 16:34 ` [PATCH v3 2/8] gzip: refactor and expand macros Daniel P. Smith
2024-04-29 14:07   ` Jan Beulich
2024-04-24 16:34 ` [PATCH v3 3/8] gzip: refactor the gunzip window into common state Daniel P. Smith
2024-04-24 21:34   ` Daniel P. Smith
2024-04-24 16:34 ` [PATCH v3 4/8] gzip: move window pointer into gunzip state Daniel P. Smith
2024-04-29 14:08   ` Jan Beulich
2024-04-24 16:34 ` [PATCH v3 5/8] gzip: move input buffer handling " Daniel P. Smith
2024-04-29 15:04   ` Jan Beulich
2024-04-24 16:34 ` [PATCH v3 6/8] gzip: move output buffer " Daniel P. Smith
2024-04-29 15:07   ` Jan Beulich
2024-04-24 16:34 ` [PATCH v3 7/8] gzip: move bitbuffer " Daniel P. Smith
2024-04-25 19:23   ` Andrew Cooper
2024-04-26  5:55     ` Jan Beulich
2024-04-26  5:57       ` Jan Beulich
2024-04-26 12:36         ` Andrew Cooper
2024-04-24 16:34 ` [PATCH v3 8/8] gzip: move crc state " Daniel P. Smith
2024-04-25 19:19   ` Andrew Cooper
2024-04-29 15:17   ` Jan Beulich
2024-04-24 16:48 ` [PATCH v3 0/8] Clean up of gzip decompressor Daniel P. Smith
2024-05-09 15:36 ` Andrew Cooper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240424163422.23276-1-dpsmith@apertussolutions.com \
    --to=dpsmith@apertussolutions.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=jason.andryuk@amd.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).