From: Richard Purdie <rpurdie@openedhand.com>
To: Nitin Gupta <nitingupta910@gmail.com>
Cc: Daniel Hazelton <dhazelton@enter.net>,
akpm <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Hugh Dickins <hugh@veritas.com>,
Nick Piggin <nickpiggin@yahoo.com.au>,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH -mm 0/5] LZO and swap write failure patches for -mm
Date: Mon, 04 Jun 2007 21:58:51 +0100 [thread overview]
Message-ID: <1180990731.6313.179.camel@localhost.localdomain> (raw)
In-Reply-To: <4cefeab80706041126y5f12402cl61b72ec101dd7915@mail.gmail.com>
On Mon, 2007-06-04 at 23:56 +0530, Nitin Gupta wrote:
> Yes there might still be problems - that is why I posted as RFC. I got
> useful comments and the code is improving. Going for such fork might
> be pain initially but IMHO its worth it. My idea for this 'fork' is
> not just clean-ups but potential optimizations that such cleanups
> usually bring along. I do not think there will be major overhauls in
> such mature de/compression implementations so I believe its okay to go
> for such 'fork' for sake of cleaner and perhaps faster code.
If you want to make cleaner and faster code, why not work on LZO
upstream directly? I'm sure the LZO author would welcome the speedups,
just as much as the kernel would.
If they're accepted into LZO, I'm nearly certain the kernel will accept
them and if the kernel code is as I've proposed, upgrading is
straightforward too. Working with "upstream" is often harder but
ultimately much more rewarding.
> Again, I am working on improving the code as per feedback. This is
> what I expect from RFC. Many people raised concerns regarding
> bloatware in your patch too, including me.
And there are concerns against your patches including:
* endian issues
* alignment issues
* potential security holes
* unexplained code generation differences
* difficulty of upgrading
Compared to the style/bloat issue, I'd say that's a fair compromise.
Regards,
Richard
next prev parent reply other threads:[~2007-06-04 20:59 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-04 15:36 [PATCH -mm 0/5] LZO and swap write failure patches for -mm Richard Purdie
2007-06-04 16:14 ` Daniel Hazelton
2007-06-04 16:52 ` Richard Purdie
2007-06-04 17:37 ` Daniel Hazelton
2007-06-04 18:34 ` Nitin Gupta
2007-06-04 20:45 ` Richard Purdie
2007-06-04 22:13 ` Daniel Hazelton
2007-06-04 18:26 ` Nitin Gupta
2007-06-04 20:06 ` Adrian Bunk
2007-06-05 5:30 ` Nitin Gupta
2007-06-05 5:50 ` Andrew Morton
2007-06-05 8:56 ` Richard Purdie
2007-06-04 20:58 ` Richard Purdie [this message]
2007-06-05 6:15 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1180990731.6313.179.camel@localhost.localdomain \
--to=rpurdie@openedhand.com \
--cc=akpm@linux-foundation.org \
--cc=dhazelton@enter.net \
--cc=dwmw2@infradead.org \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
--cc=nitingupta910@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox