Herbert,
I also wonder, does it at all correct to use negative windowBits in crypto API? I mean, if windowBits is negative, zlib doesn't produce the proper zstream header, which is incorrect according to RFC-1950. It also doesn't calculate adler32.
For example, if we work over an IP network (RFC-2384), the receiving side may be confused by such a "stripped" zstream.
Isn't it conceptually right to produce *correct* zstream, with the header and the proper adler32 ?
Yes, for JFFS2 we would like to have no adler32, we anyway protect our data by CRC32. But I suppose this should be an additional feature.
Comments?
Herbert Xu wrote:
I made the changes to deflate_decompr() because the old version doesn't work properly for me. There are 2 changes.
1. I've added the following code:
------------------------------------------------------------------------ if (slen > 2 && !(src[1] & PRESET_DICT) /* No preset dictionary */ && ((src[0] & 0x0f) == Z_DEFLATED) /* Comp. method byte is OK */ && !(((src[0] << 8) + src[1]) % 31)) { /* CMF*256 + FLG */ stream->next_in += 2; stream->avail_in -= 2; } ------------------------------------------------------------------------
The reason you need to add this is because the window bits that was used to produce the compressed data is positive while the window bits crypto/deflate is using to perform the decompression isn't.
So what we should do here is turn window bits into a configurable parameter.
Once you supply the correct window bits information, the above is then simply an optimisation.
Rather than keeping the above optimisation, JFFS should simply do the compression with a negative window bits value.
Of course to maintain backwards compatibility you'll need to do this
as a new compression type.
-- Best Regards, Artem B. Bityuckiy, St.-Petersburg, Russia. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
