Re: [RFC] CryptoAPI & Compression

[Artem B. Bityuckiy]

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?

--
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/