cryptoapi compression modules & JFFSx

cryptoapi compression modules & JFFSx

[Kluba, Patrik]

Hi everybody,

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.

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?

Regards,

   Patrik Kluba

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@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: cryptoapi compression modules & JFFSx

[Artem B. Bityuckiy]

Kluba, Patrik wrote:
> 
> Hi everybody,
> 
> I'm going to port JFFS2's compression modules to CryptoApi except  
> {in|de}flate, which Artem is working(?) on.
No, I don't work on that anymore, so you probably want to port deflate 
as well. My investigation showed that it can't be easily done without 
hacking zlib internals, unless you greatly lose the compression ratio by 
flushing the zstream and do other ugly things.

Nevertheless, you're the compression specialist(s), so you should do 
this better :-)


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