Re: [RFC] CryptoAPI & Compression

Artem B. Bityuckiy
2005-04-19T12:52:19Z

Herbert Xu wrote:
>>Actually, for JFFS2 we need to leave the uncompressable data
>>uncompressed. So if the pcompress interface have only been for JFFS2,
>>I'd just return an error rather then expand data. Is such behavior
>>acceptable for common Linux's parts pike CryptoAPI ?
> You mean you no longer need pcompress and we can get rid of it?
> That's fine by me.

Pardon Herbert, I didn't say anything about getting rid yet :-) I've
just reread what I wrote and didn't find a drop of that :-) But if I was
fuzzy, I'm sorry.

I meant there are 2 situations:
1. input data is compressible;
2. input data isn't compressible.

JFFS2 wants the following from pcompress():
1. compressible data: compress it; the offered formerly algorithm works
just fine here.
2. non-compressible data: do not compress it, leave it uncompressed; the
offered algorithm works fine here too - it returns an error.

So, the essence of the question was: the offered algorithm is OK for
JFFS2 (but need some refining). May we preserve it and don't bother
about predicting how much buffer space we need to reserve in case the
input data is non-compressible?