On 1/27/2016 4:09 PM, Herbert Xu wrote:
On Wed, Jan 27, 2016 at 04:03:55PM +0800, Herbert Xu wrote:
On Wed, Jan 27, 2016 at 03:59:05PM +0800, Li, Weigang wrote:
The acomp is also SG-based, while scomp only accepts flat buffer.
Right, but do we need a pointer-based scomp at all? IPComp would
certainly be better off with an SG-based interface. Any other
users of compression are presumably dealing with large amounts
of data where an SG interface would make more sense.
A pointer interface makes sense for shash because you may be hashing
16 bytes at a time. Nobody sane is going to be compressing 16 bytes,
or are they?
Note that I'm fine with keeping an scomp interface underneath
for those algorithms where the best way to handle SG input is
to linearise things. But I would prefer that this interface is
not exposed to kernel users unless it is absolutely required.
Cheers,
Thanks for your comments, Herbert. I Agree, SG-list based compression
API makes more sense. Maybe Joonsoo can comment on this.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
