Thanks for the patches! 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? > 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. > 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. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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
