Re: [PATCH] Add LZO1X compression support to the kernel
- From: devzero@xxxxxx
- Date: Fri, 11 May 2007 22:48:15 +0200
Why is this needed? What code plans to use it?
it`s pretty useful because it`s and a damn fast and damn cpu friendly compression alorithm.
afaik, there is already a least one linux kernel-feature (under development) which is using lzo compression:
see compressed caching project at http://linux-mm.org/CompressedCaching & http://linuxcompressed.sourceforge.net/
seems, they have also done porting it to the kernel, so there is probably choice between two implemetations to merge.
How many buffer overruns are there in it?
i don`t know :)
but, from a user-perspective, lzo is really portable and seems to be a rock solid compression scheme.
i`m sucessfully using it for years (lzop utility) and i know projects which compress gigabytes of data every day with lzop.
furthermore, i know of at least 40 software projects using lzo compression, so this should have some level of maturity.
maybe i can add another software integrating lzo compression to the enumeration at http://www.lzop.de ? ;)
regards
roland
List: linux-kernel
Subject: Re: [PATCH] Add LZO1X compression support to the kernel
From: Andrew Morton <akpm () linux-foundation ! org>
Date: 2007-05-10 6:21:29
Message-ID: 20070509232129.371f49d5.akpm () linux-foundation ! org
[Download message RAW]
On Wed, 02 May 2007 09:56:23 +0100 Richard Purdie <richard@xxxxxxxxxxxxxx> wrote:
Current thinking is that lzo should get merged directly followed by the
subsystem parts through their specific trees. It appears this should
make it onto LKML despite the size so here goes.
Please keep in mind I haven't reformatted the LZO code itself as if I do
so, it will make maintenance of it against any changes in LZO itself
near impossible. In its current form, it should be possible to diff
against upstream. All the bad formatting is confined to a handful of
files in lib/lzo/ and the kernel interface should be clean.
I realise a maze of ifdefs still remain. I've already spent a lot of
time removing a ton of them and going much further might start to affect
diffability of the code - I hoping whats there is a good compromise.
I've asked the LZO author about the comments on lzo_copyright function
but the code is GPLv2 licensed so is suitable for inclusion in the
kernel.
Add LZO1X compression/decompression support to the kernel.
This is based on the standard userspace lzo library, particularly
minilzo with the headers much trimmed down and simplified for kernel
use. Its structured so that it should still diff with the userspace
version for ease of future updating.
Well that's attractive-looking code.
Why is this needed? What code plans to use it?
How many buffer overruns are there in it?
_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: [PATCH] Add LZO1X compression support to the kernel
- From: Jindrich Makovicka
- Re: [PATCH] Add LZO1X compression support to the kernel
- Prev by Date: Re: [PATCH] module_author: don't advice putting in an email address
- Next by Date: Re: [patch] CFS scheduler, -v8
- Previous by thread: Re: [PATCH] Add LZO1X compression support to the kernel
- Next by thread: Re: [PATCH] Add LZO1X compression support to the kernel
- Index(es):
Relevant Pages
|
