[lkml]   [2005]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] CryptoAPI & Compression
Hi Artem:

On Tue, Mar 29, 2005 at 12:55:11PM +0100, Artem B. Bityuckiy wrote:
> I'm not sure. David Woodhouse (the author) said that this is probably
> enough in any case but a lot of time has gone since the code was written
> and he doesn't remember for sure. I have also seen some magic number "12"
> somewhere in zlib, but I'm not sure.
> At least my practice shows that 12 is Ok for JFFS2 where we compress fewer
> then 4K a a time. I'll explore this.

The crypto API needs to operate on buffers that's bigger than that so
we need to have a correct upper bound the maximum expansion.

> > We normally put the operator on the preceding line, i.e.,
> >
> > while (foo &&
> > bar) {
> If this is the the common practice for Linux, then OK. My argument is the
> GNU Coding style which recommends:

The GNU coding style is completely different from Linux.

> Ok. This is not the final patch but more like RFC and I can re-format and
> re-send it. :-) Please, feel free to re-format it as you would like
> yourself.

Please reformat it when you fix up the overhead calculation.

> And one more thing I wanted to offer. In the
> deflate_[compress|uncompress|pcompress] functions we call the
> zlib_[in|de]flateReset function at the beginning. This is OK. But when we
> unload the deflate module we don't call zlib_[in|de]flateEnd to free all
> the zlib internal data. It looks like a bug for me. Please, consider the
> attached patch.

Good catch. I'll apply this one.

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.062 / U:4.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site