Artem B. Bityuckiy <[email protected]> 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~} <[email protected]>
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
