[lkml]   [2005]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] CryptoAPI & Compression
Artem B. Bityuckiy <> 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


> 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.

Visit Openswan at
Email: Herbert Xu ~{PmV>HI~} <>
Home Page:
PGP Key:
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-04-06 13:31    [W:0.092 / U:32.916 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site