Re: [RFC] CryptoAPI & Compression

Herbert Xu
2005-03-31T02:22:51Z

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