[v2,0/6] Clean up of gzip decompressor

Message

Daniel P. Smith April 17, 2024, 2:37 p.m. UTC

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 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 (6):
  gzip: drop unused define checks
  gzip: clean up comments and fix code alignment
  gzip: remove custom memory allocator
  gzip: refactor state tracking
  gzip: move crc state into consilidated gzip state
  gzip: drop huffman code table tracking

 xen/common/gzip/gunzip.c  |  87 ++--
 xen/common/gzip/inflate.c | 974 ++++++++++++++++++--------------------
 2 files changed, 501 insertions(+), 560 deletions(-)

Comments

Jan Beulich April 18, 2024, 7:43 a.m. UTC | #1

On 17.04.2024 16:37, Daniel P. Smith wrote:
> 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.

I don't mind the content and style adjustments, but what I'm missing here and
in the patch descriptions is weighing of doing so versus ease of importing
changes to the original source.

Jan