[PATCH/RFC] crypto: compress - Add comp_request.total_out (was: Re:[PATCH 6/6] squashfs: Make SquashFS 4 use the new pcomp crypto interface)

From: Geert Uytterhoeven
Date: Tue Mar 17 2009 - 08:54:25 EST


On Wed, 11 Mar 2009, Geert Uytterhoeven wrote:
> On Sun, 8 Mar 2009, Phillip Lougher wrote:
> > Two API issues of concern (one major, one minor). Both of these relate to the
> > way Squashfs drives the decompression code, where it repeatedly calls it
> > supplying additional input/output buffers, rather than using a "single-shot"
> > approach where it calls the decompression code once supplying all the
> > necessary input and output buffer space.
> >
> > 1. Minor issue -the lack of a stream.total_out field. The current
> > zlib_inflate code collects the total number of bytes decompressed over the
> > multiple calls into the stream.total_out field.
> >
> > There is clearly no such field available in the cryto API, leading to the
> > somewhat clumsy need to track it, i.e. it leads to the following additional
> > code.
>
> If people feel the need for a total_out field, I can add it to struct
> comp_request.
>
> BTW, what about total_in, which is also provided by plain zlib's z_stream?
> Do people see a need for a similar field?

The patch below (on top of the updated one to convert SquashFS to pcomp) adds
comp_request.total_out, so you don't have to calculate and accumulate the
decompressed output sizes in SquashFS.

Notes:
- This required the addition of a `struct comp_request *' parameter to
crypto_{,de}compress_init()
- Still, there's one of the

produced = req.avail_out;
...
produced -= req.avail_out;

left, as this is part of the logic to discover the end of decompression
(no bytes produced, no error returned).

Perhaps it's better to instead make crypto_{,de}compress_{update,final}()
return the (positive) number of output bytes (of the current step)?

Currently it returns zero (no error) or a negative error value.
That would allow to get rid of both `produced = ... / produced -= ...'
constructs, but the user would have to accumulate the total output size again
(which is not such a big deal, IMHO).

Thanks for your comments!