[lkml]   [2005]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] CryptoAPI & Compression
    Artem B. Bityuckiy <> wrote:
    >> Good catch. I'll apply this one.
    > Only one small note: I've spotted this but didn't test. I didn't make
    > sure this is OK if we haven't ever used the compression and remove the
    > deflate module. (i.e, in this case we call zlib_[in|de]flateEnd() while
    > we haven't ever called zlib_[in|de]flate()). Although I believe it must
    > be OK, we need to try it.

    It's OK because deflateReset == deflateEnd + deflateInit. Feel free
    to test it though. You can find my tree at


    > So, it seems I can't just port the JFFS2 stuff. I need to explore zlib
    > more closely. Thus, I need some time. I'll inform you about my results.

    For the default zlib parameters (which crypto/deflate.c does not use)
    the maximum overhead is 5 bytes every 16KB plus 6 bytes. So for input
    streams less than 16KB the figure of 12 bytes is correct. However,
    in general the overhead needs to grow proportionally to the number of
    blocks in the input.

    Visit Openswan at
    Email: Herbert Xu ~{PmV>HI~} <>
    Home Page:
    PGP Key:
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-04-06 13:31    [W:0.020 / U:19.348 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site