lkml.org 
[lkml]   [2005]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] CryptoAPI & Compression


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

\
 
 \ /
  Last update: 2005-04-19 14:56    [W:0.151 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site