Messages in this thread | | | Date | Thu, 31 Mar 2005 12:19:10 +1000 | Subject | Re: [RFC] CryptoAPI & Compression | From | Herbert Xu <> |
| |
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.
Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |