All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Hazelton <dhazelton@enter.net>
To: Richard Purdie <rpurdie@openedhand.com>
Cc: 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>,
	Nitin Gupta <nitingupta910@gmail.com>
Subject: Re: [PATCH -mm 0/5] LZO and swap write failure patches for -mm
Date: Mon, 4 Jun 2007 18:13:55 -0400	[thread overview]
Message-ID: <200706041813.55419.dhazelton@enter.net> (raw)
In-Reply-To: <1180989955.6313.168.camel@localhost.localdomain>

On Monday 04 June 2007 16:45:55 Richard Purdie wrote:
> On Mon, 2007-06-04 at 13:37 -0400, Daniel Hazelton wrote:
> > Yes - most of that work, IIRC, is related to the alignment issues that
> > Herr Oberhumer noted. As it stands, the alternative does work well for a
> > large number of the platforms that the kernel supports. With a little
> > Kconfig magic it could be made available *only* for those platforms that
> > it currently supports. Then people can help work on the alignment issues
> > - possibly by providing platform conditional code.
>
> My patch was actually written with ARM machines in mind and has been
> extremely well tested on it. A version which doesn't run on ARM is not
> acceptable. Its also ironic that "platform conditional code" is what a
> lot of that bloat you're so keen to remove is about.

Done in a very poor manner.

> > I'm not familiar with the zlib code, but it was included a long time ago
> > - since zlib was included I'm pretty certain that if it had been proposed
> > today it would have been NACK'd for the style violations and bloat.
>
> Adrian's covered this. I also know how hard updating something like zlib
> is (I was the last person to do it).

I do agree. I have looked over the zlib code and it is very involved - I, 
personally, would not like to have to maintain it if I couldn't easily diff 
it against userspace.

> > You can take the time to produce a patch and spread FUD about the speed
> > of a competing patches code but you don't have the time to work on fixing
> > a cleaner implementation? I'll admit that actually working on fixing
> > problems in code can take more time, but still - the time taken for those
> > pursuits *could* have been spent actually working on fixing the problems.
>
> I *have* spent some time on it.
>
> My speed comments were actually pretty positive. Yes, I screwed up one
> of the benchmarks (as have others proving its easily done) but I did
> admit to it. My others were fair comment and some issues were addressed
> as a result (but not all).

I've looked back over the entire spread of the messages, both from before I 
wrote that quick&dirty benchmark and after. Maintainability is a good thing 
to aim for, however the style used to achieve the complete cross-platform 
mobility could be handled a lot cleaner - give me a few days to really study 
the LZO code and I'll see if I can't reach a middle-ground - code that is 
easy to maintain (and diff against userspace) as well as being stripped to 
its core and very cleanly implemented.

I can't promise results, but I figure I'm at fault for really starting this 
current spate of flames so I should at least take responsibility and do 
something to try and put them out. What I can say, at this point, is that a 
lot of my changes will be in making the code comply to kernel-style in a 
manner *similar* to how Nitin has done it - collapse redundant code together, 
replace open-coded blocks with calls to library functions, etc...


> I'm going to stop here. I don't agree with the rest of your email and
> you've a distorted view of whats been said.

Hindsight is sometimes too perfect. I should have returned to the early posts 
for clarity before making a lot of the comments I did. It shames me to admit 
that I've made such a nasty mistake and made myself seem like nothing more 
than a common troll.

Apologetically,
DRH

  reply	other threads:[~2007-06-04 22:14 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 [this message]
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
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=200706041813.55419.dhazelton@enter.net \
    --to=dhazelton@enter.net \
    --cc=akpm@linux-foundation.org \
    --cc=dwmw2@infradead.org \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=nitingupta910@gmail.com \
    --cc=rpurdie@openedhand.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.