lkml.org 
[lkml]   [2005]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] CryptoAPI & Compression
From
Date
On Sun, 2005-04-03 at 20:17 +1000, Herbert Xu wrote:
> You might be right. But I'm not sure yet.
>
> If we use the current code and supply zlib_deflate with 1048576-12
> bytes of (incompressible) input and 1048576 bytes of output buffer,
> wouldn't zlib keep writing incompressible blocks and return when it
> can't do that anymore because the output buffer has been exhausted?
>
> When it does return it has to finish writing the last block it's on.
>
> So if the total overhead is 32 bytes then the last block would need
> another 20 bytes of output space which we don't have, no?

Right. We shouldn't feed 1048576-12 bytes into zlib and expect the
output to fit into our 1048576-byte buffer. We could get away with that
kind of thing when we were using Z_SYNC_FLUSH but we can't now.

But now we're not using Z_SYNC_FLUSH it doesn't matter if we feed the
input in smaller chunks. We can calculate a conservative estimate of the
amount we'll fit, and keep feeding it input till the amount of space
left in the output buffer is 12 bytes.

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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