Geert Uytterhoeven wrote:
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?
From a quick look, it looks OK :-) I'm not ignoring this, but I'm trying to get a release of
the 4.0 tools finished ASAP (now 2.6.29 is out).
Phillip
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
