lkml.org 
[lkml]   [2005]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Subject[RFC] CryptoAPI & Compression
    From
    Date
    Hello Herbert and others,

    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 isn't
    flexible enough 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 (in the compressed form) to
    the output buffer. To put it differently, we often have a large input,
    and several smalloutput 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.

    Alternatively, we may create some kind of "Compression API" but I don't
    like this idea...

    Comments?

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

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-04-06 13:30    [W:4.279 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site