[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4cefeab80705280509x73c8a1c9m9e8ba58d235a3666@mail.gmail.com>
Date: Mon, 28 May 2007 17:39:22 +0530
From: "Nitin Gupta" <nitingupta910@...il.com>
To: "Michael-Luke Jones" <mlj28@....ac.uk>
Cc: lkml <linux-kernel@...r.kernel.org>, linux-mm-cc@...top.org,
linuxcompressed-devel@...ts.sourceforge.net,
"Andrew Morton" <akpm@...ux-foundation.org>,
"Richard Purdie" <richard@...nedhand.com>,
"Daniel Hazelton" <dhazelton@...er.net>,
"Bret Towe" <magnade@...il.com>,
"Satyam Sharma" <satyam.sharma@...il.com>
Subject: Re: [RFC] LZO de/compression support - take 5
On 5/28/07, Michael-Luke Jones <mlj28@....ac.uk> wrote:
> On 28 May 2007, at 07:59, Nitin Gupta wrote:
>
> > If we get no perf. problems with this patch, then I beleive it is now
> > suitable to inclusion in mainline. Further cleanups and optimizations
> > can surely be done after that. It's still just ~500 LOC.
>
> Before LZO code is sent to Linus, its selection in Kconfig should be
> made orthogonal to the current zlib selection code.
>
> This means:
> 1) Options in lib/Kconfig hidden (selectable by drivers as required)
LZO as hidden option has no practical sense. Although LZO should be
auto-selected when some dependent project is selected (e.g. reieser4)
- there should be separate patch for this. Mixing such changes with
'core' LZO patch will just add side noise.
> 2) Decompression and Compression support separated, as read-only
> filesystems only need to build in decompression support.
>
Ok, I will do this. I wonder if some difference in opinion in such
things can actually cause 10+ extra RFCs?
Cheers,
Nitin
-
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/
Powered by blists - more mailing lists