*********** REPLY SEPARATOR ***********
On 4/27/2003 at 11:04 AM Jörn Engel wrote:
>On Sat, 26 April 2003 22:24:04 -0400, rmoser wrote:
>>
>> So what's the best way to do this? I was originally thinking like this:
>>
>> Grab some swap data
>> Stuff it into fcomp_push()
>> When you have 100k of data, seal it up
>> Write that 100k block
>
>I would like something like this:
>
>/* fox_compress
> * @input: Pointer to uncompressed data
> * @output: Pointer to buffer
> * @inlen: Size of uncompressed data
> * @outlen: Size of the buffer
> *
> * Return:
> * 0 on successful compression
> * -Esomething on error
> *
> * Side effects:
> * Output buffer is filled with random data after an error
> * condition or the compressed input data on success.
> * outlen remains unchanged on error and holds the compressed
> * data size on success
> *
> * If the output buffer is too small, this is an error.
> */
>int fox_compress(unsigned char *input, unsigned char *output,
> uint32_t inlen, uint32_t *outlen);
>
>/* fox_decompress
> * see above, basically
> */
>int fox_decompress(unsigned char *input, unsigned char *output,
> uint32_t inlen, uint32_t *outlen);
>
Ey? uint32_t*? I assume that's a mistake.... Anyhow, this wasn't what
I was asking. What I was asking was about how to determine how much
data to send to compress it. Read the message again, the whole thing
this time.
>Then the mm code can pick any useful size for compression.
>
>Jörn
Eh? I rather the code alloc space itself and do all its own handling. That
way you don't have to second-guess the buffer size for decompressed
data if you don't do all-at-once decompression (i.e. decompressing x86
segments, all-at-once would be to decompress the whole compressed
block of N size to 64k, where partial would be to pull in N/n at a time and
decompress in n sets of N/n, which would give varying sized output).
Another thing is that the code isn't made to strictly stick to compressing
or decompressing a whole input all at once; you may break down the
input into smaller pieces. Therefore it does need to think about how much
it's gonna actually tell you to pull off when you inquire about the size to
remove from the stream (for compression at least), because you might
break it if you pull too much data off midway through compression. The
advantage of this method is in when you're A) Compressing files, and
B) trying to do this kind of thing on EXTREMELY low RAM systems,
where you can't afford to pass whole buffers back and forth. (Think 4 meg)
You do actually understand the code, right? I have this weird habit of
making code and doing such obfuscating comments that people go
"WTF is this?" when they see it. Then again, you're probably about
12 classes past me in C programming, so maybe it's just my logic that's
flawed. :)
--Bluefox Icy
(John Moser in case something winds up with my name on it)
>
>--
>My second remark is that our intellectual powers are rather geared to
>master static relations and that our powers to visualize processes
>evolving in time are relatively poorly developed.
>-- Edsger W. Dijkstra
>-
>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/
-
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/
This archive was generated by hypermail 2b29 : Wed Apr 30 2003 - 22:00:26 EST