public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


  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