Re: [RFC] CryptoAPI & Compression

[Herbert Xu]

Artem B. Bityuckiy <dedekind@xxxxxxxxxxxxx> wrote:
> 
>> Good catch.  I'll apply this one.
> Only one small note: I've spotted this but didn't test. I didn't make
> sure this is OK if we haven't ever used the compression and remove the
> deflate module. (i.e, in this case we call zlib_[in|de]flateEnd() while
> we haven't ever called zlib_[in|de]flate()). Although I believe it must
> be OK, we need to try it.

It's OK because deflateReset == deflateEnd + deflateInit.  Feel free
to test it though.  You can find my tree at

bk://herbert.bkbits.net/cryptodev-2.6

> So, it seems I can't just port the JFFS2 stuff. I need to explore zlib
> more closely. Thus, I need some time. I'll inform you about my results.

For the default zlib parameters (which crypto/deflate.c does not use)
the maximum overhead is 5 bytes every 16KB plus 6 bytes.  So for input
streams less than 16KB the figure of 12 bytes is correct.  However,
in general the overhead needs to grow proportionally to the number of
blocks in the input.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/