Crypto API extention request

[Artem B. Bityuckiy]

Hello James,

I'm an JFFS2/JFFS3 developer and I'm working on cleaning-up the JFFS3
compression stuff. JFFS3 contains a number of compressors which actually
shouldn't be there as they are platform-independent and generic. So we
want to move them to the generic part of the Linux kernel instead of
storing them in fs/jffs2/. And we were going to use CryptoAPI to access
the compressors.

But I've hit on a problem - CryptoAPI's compression method is too poor
for us.

CryptoAPI's compress method is:

int crypto_compress(struct crypto_tfm *tfm,
                    const u8 *src, unsigned int slen,
                    u8 *dst, unsigned int *dlen);

*src - input data;
slen - input data length;
*dst - output data;
*dlen - on input - output buffer length, on output - the length of the
compressed data;

The crypto_compress() API call either compresses all the input data or
returns error.

In JFFS2 we need something more flexible. Te following is what we want:

int crypto_compress_ext(struct crypto_tfm *tfm,
                    const u8 *src, unsigned int *slen,
                    u8 **dst, unsigned int *dlen);

*src - input data;
*slen - on input - input data length, on output - the amount of data
that were actually compressed.
*dst - output data;
*dlen - on input - output buffer length, on output - the length of the
compressed data;

This would allow us (and we really need this) to provide a large input
data buffer, a small output data buffer and to ask the compressor to
compress as much input data as it can to fit to the output buffer. To
put it differently, we often have a large input, and several small
output buffers, and we want to compress the input data to them.

I offer to extend the CryptoAPI and add an "extended compress" API call
with the above mentioned capabilities. We might as well just change the
crypto_compress() and all its users.

What do you think?

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.