[PATCH/RFC] crypto: compress - Return produced bytes incrypto_{,de}compress_{update,final}() (was: Re: [PATCH/RFC] crypto: compress- Add comp_request.total_out (was: Re: [PATCH 6/6] squashfs: Make SquashFS4 use the new pcomp crypto interface))

[Geert Uytterhoeven]

On Tue, 17 Mar 2009, Geert Uytterhoeven wrote:
> 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).

Here's an alternative patch, which does exactly that.
Phillip, what do you think?

Thanks for your comments!