lkml.org 
[lkml]   [2009]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH/RFC] crypto: compress - Return produced bytes in crypto_{,de}compress_{update,final}() (was: Re: [PATCH/RFC] crypto: compress - Add comp_request.total_out
    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


    \
     
     \ /
      Last update: 2009-03-25 11:15    [W:0.031 / U:59.320 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site