Re: [RFC] CryptoAPI & Compression

[Herbert Xu <herbert@gondor.apana.org.au>]

On Sun, Apr 03, 2005 at 04:01:19PM +0400, Artem B. Bityuckiy wrote:
> 
> >For instance for JFFS2 it's absolutely incorrect since it breaks
> >compatibility.  Incidentally, JFFS should create a new compression
> >type that doesn't include the zlib header so that we don't need the
> >head-skipping speed hack.
>
> Anyway, in JFFS2 we may do that "hack" before calling pcompress(), so it 
> isn't big problem.

It still makes sense to use a negative window bits for JFFS since it
means that you don't have to calculate the adler checksum in the
first place AND you don't have to store the zlib header/trailer on
disk.

BTW, that hack can only be applied when there is no preset dictionary.
Although the Linux implementation of JFFS probably never used a preset
dictionary, it is theoretically possible that someone out there may
have generated a JFFS image which contains a compressed stream that has
a preset dictionary.

In that case if you don't set the window bits to a postive value it
won't work at all.

> >Yes, I'd love to see a patch that makes windowBits configurable in
> >crypto/deflate.c.
>
> I wonder, do we really want this?

Yes since the the window bits determines the compression quality and
the amount of memory used.  This is going to differ depending on the
application.

> Imagine we have 100 different compressors, and each is differently 
> configurable. It may make cryptoAPI messy. May be it is better to stand 
> that user must use deflate (and the other 99 compressors) directly if he 
> wants something not standard/compliant?

Each crypto/deflate user gets their own private zlib instance.
Where is the problem?

Cheers,
-- 
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/