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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a781481a0705121251o5faedbc2ybfef61efdee90864@mail.gmail.com>
Date:	Sun, 13 May 2007 01:21:13 +0530
From:	"Satyam Sharma" <satyam.sharma@...il.com>
To:	"Jindrich Makovicka" <makovick@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Add LZO1X compression support to the kernel

Hi Jindrich,

On 5/12/07, Jindrich Makovicka <makovick@...il.com> wrote:
> On Sat, 12 May 2007 12:41:03 +0200
> devzero@....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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/