On Tue, 25 Nov 2008, Herbert Xu wrote:
> On Mon, Nov 24, 2008 at 05:11:42PM +0100, Geert Uytterhoeven wrote:
> > As pointed out in patch [1/4], some underlying (de)compression implementations
> > do not support partial (de)compression. This is the case for e.g. LZO, which
> > is already supported by a crypto module. While one-shot (de)compression can
> > easily be implemented on top of a partial (de)compression API, the inverse is
> > not true.
>
> But that's just because lib/lzo didn't implement partial operations,
> which means that we can improve it to perform partial compression and
> decompression, right?
That's right. If the actual algorithm supports it, lib/lzo can be enhanced.
> > Hence there should be a way to ask for a "one-shot" vs. "partial" decompression
> > module at crypto_alloc_comp() time.
>
> If we do find such an algorithm (which I'm sceptical), then we can
> easily add such a flag which can be used at alloc time to choose
> the right type.
>
> In fact, even if such algorithm did exist (i.e., one that requires
> all the input to determine the first byte of the output), we can
> always handle it by only ever writing output in the final function.
Indeed. Whether the users can handle it is a different question. Current
Squashfs assumes the decompressor always consumes all input bytes on each and
every call.
> > Do you have any suggestions how to handle this?
> > Perhaps by using "oneshot(%s)" and "partial(%s)", cfr. what is done in other
> > parts of the CRYPTO API where orthogonal features are combined?
>
> The standard way is to add a CRYPTO_ALG_FOO flag and use it at
> alloc time.
>
> But I really can't imagine how such an algorithm could possibly
> work beyond a fixed size input.
>
> Also, I'm not saying that you need to convert lzo yourself since
> you can always add a new compress type alongside the existing
> crypto_comp type. When someone does finally convert lzo we can
> then kill the old type. See the shash/digest code for an example
> of such a cohabitation.
OK.
On Tue, 25 Nov 2008, Herbert Xu wrote:
> On Mon, Nov 24, 2008 at 05:12:37PM +0100, Geert Uytterhoeven wrote:
> > To solve this, add the following operations that support partial
> > (de)compression:
> > - crypto_compress_{init,update,final}() for compression,
> > - crypto_decompress_{init,update,final}() for decompression.
>
> Probably best to put this in a new type instead of crypto_comp.
> That way you can still get a bisectable tree without having to
> lump everything into one patch.
OK, I'll create a new crypto_* type.
> Doing that also means that you don't have to convert all the algorithms
> at once (but please do convert them eventually so I don't have to :)
Currently the only (de)compression algorithms supported by crypto/ are
deflate/zlib and lzo, so there's not that much to convert/migrate.
Obviously I'll take care of deflate/zlib.
> To make the conversion happen gradually you'd make all algorithms
> of the new type available through the existing type (crypto_comp).
> See how crypto_shash handles this with regards to the existing
> crypto_hash type.
OK, I'll look into that.
> Once all algorithms are converted then you can convert the existing
> users (new users can begin using the new type immediately). Finally
> you'd kill the crypto_comp type.
OK.
Thx!
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@xxxxxxxxxxx
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
--
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
