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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
