On Thu, Jun 26, 2008 at 06:07:29PM +0200, Geert Uytterhoeven wrote:
>
> But it also means it's not so easy to avoid allocating the compression buffer
> if you need decompression only. Or am I missing something?
Well there are ways to solve this, e.g., by creating new interfaces
that are compressio
On Thu, 26 Jun 2008, Herbert Xu wrote:
> Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
> > 2. Why was the lazy allocation removed back in 2004?
> > If you're interested in decompression only, it's a bit wasteful to
> > allocate 262 KiB of memory for compression and never use it.
>
> The b
Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
>
> 2. Why was the lazy allocation removed back in 2004?
> If you're interested in decompression only, it's a bit wasteful to
> allocate 262 KiB of memory for compression and never use it.
The burden to save memory was simply moved to the use
* Geert Uytterhoeven | 2008-06-26 09:14:51 [+0200]:
>On Wed, 25 Jun 2008, Sebastian Siewior wrote:
>> see. Other zlib users like ppp or jffs2 user zlib directly. However, the
>> crypto API is the only place in kernel which provides you a generic
>> interface for compression.
>
>Indeed. So if a har
On Wed, 25 Jun 2008, Sebastian Siewior wrote:
> * Geert Uytterhoeven | 2008-06-25 19:26:28 [+0200]:
> >I have a few questions about the "deflate" crypto module (crypto/deflate.c).
> >
> > 1. Why does it support decompression of full chunks only (i.e. all
> > compressed
> > data has to be pass
