Re: [PATCH] Add LZO1X compression support to the kernel

["Satyam Sharma" <satyam.sharma@gmail.com>]

Hi Jindrich,

On 5/12/07, Jindrich Makovicka <makovick@gmail.com> wrote:
> On Sat, 12 May 2007 12:41:03 +0200
> devzero@web.de wrote:
>
> > oh - and think of linux software suspend.
> > take a notebook with 2 GB of ram - that takes a while to write that
> > to disk and read that back again. using lzo compression for this may
> > probably halve the time for suspend/resume
>
> There were already some attempts on merging of the lzf algorithm:
>
> http://lkml.org/lkml/2006/6/26/215

Hmmm ... that thread had some really neat and simple kernel-compliant
code, but it wanted to bring in a different compression algo :-) LZF, LZO,
LZW are all different.

> Also, ffmpeg/libavcodec contains a much cleaner implementation of LZO

Yeah, I hope the discussion here shifts (after the copyright issues
are resolved,
of course) to the submitted code itself. It's a compression library
also linked to
cryptoapi, so would definitely find users for itself -- this was later
submitted as
a patchset containing the JFFS2 glue code too.

But what I'm not sure about is the suitability of _this_ implementation to be
merged AS IS (~2500 lines of non-kernel-style, and even pointless, code is
no small thing) without a proper conversion / port to the kernel.

The upsides of a proper port would be nice: I suspect ~500 LOC in those
two headers would vanish, and perhaps an equal number in lzo.c (it even
re-invents memset, memcpy, etc for itself!).

The downside, as Richard said, would be that the kernel's LZO is no longer
diff-able with minilzo (the userspace library) which means someone who
takes on maintainership of this will have more work to do. (but how much
more would it be anyway?)

> decompressor, with comparable performance (but no compressor yet I am
> afraid).

Satyam