Re: cryptoapi compression modules & JFFSx

[Herbert Xu]

On Thu, Jun 23, 2005 at 07:33:37PM +0000, Kluba, Patrik wrote:
> 
> I'm going to port JFFS2's compression modules to CryptoApi except  
> {in|de}flate, which Artem is working(?) on.
> I've noticed that the pcompress thing (slen <-> *slen and partial  
> compression which about a discussion was on the list) is in Herbert's  
> repository. Does it mean that it will get into the kernel once? I just  
> would like to be sure whether should I implement pcompress or not.

Well I've removed it actually because Artem said he didn't need it
anymore.

However, if you can provide an implementation of pcompress for deflate
that's generic enough then I'm happy to put it back.  By genericity
I mean not making assumptions such as the input buffer size being
less than 4K.

> The second thing is that we would like to use CryptoApi from user  
> space. This way it won't be necessary to reimplement compression  
> algorithms in user space filesystem image creation programs  
> (mkfs.jffsx), and it would make using & distributing closed-source  
> proprietary compression methods easier.
> There's a patch at http://www.logix.cz/michal/devel/cryptodev/, written  
> by Michal Ludvig, which adds a /dev/crypto device for this purpose, as  
> on *BSD. Is there a chance that this can get into the kernel?

Something liks this will be included once we have async crypto.  However,
that could be a while yet so I suggest that you start by including the
deflate implementation in user-space.

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/