public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Gerard Lledo <gerard.lledo@gmail.com>
Cc: akpm@linux-foundation.org, linux-mtd@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [JFFS2] jffs2_start_garbage_collect_thread() return value cleanup
Date: Wed, 24 Jun 2009 11:09:01 +0100	[thread overview]
Message-ID: <1245838141.25547.5207.camel@macbook.infradead.org> (raw)
In-Reply-To: <1243944686-7039-2-git-send-email-gerard.lledo@gmail.com>

On Tue, 2009-06-02 at 15:11 +0300, Gerard Lledo wrote:
> There is no user of this return value in the kernel.  Change it to return void
> instead.

NAK. I hate this type of patch.

A function _should_ return an error value indicating success or failure,
if there's _any_ chance that it (or a future rewrite of it) may fail.

It's up to the _callers_ to act on that result, or not, as they see fit.

If you don't do that, you end up with whole stacks of functions which
neither handle nor propagate errors -- and it's a _complete_ pain when
you later find that you _do_ have to make one of the innermost functions
return an error.

Gerard, if you persist in sending this kind of patch, please could I ask
you to send me a cloth doll of yourself? I would like to stick pins in
it next time I have to retrofit error handling to a stack of functions
that lack it.

It's not even as if this patch is going to give any real performance
improvement. It's a single register load in a once-per-mount code path.

There _may_ be some places where this kind of patch is reasonable -- but
the commit comment should have a clear explanation of why the return
value will _never_ be needed, rather than merely observing that it is
not _currently_ used. Or show that there is a _significant_ improvement
obtained by doing so, perhaps.

Andrew, may I suggest that you look for such justification in future
patches of this type?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

  parent reply	other threads:[~2009-06-24 10:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-29  8:19 [PATCH] [JFFS2] Move jffs2_gcd_mtd threads to the new kthread API Gerard Lledo
2009-06-01 23:20 ` Andrew Morton
2009-06-02 11:32   ` Gerard Lledo
2009-06-02 12:11     ` Gerard Lledo
2009-06-02 12:11       ` [PATCH] [JFFS2] jffs2_start_garbage_collect_thread() return value cleanup Gerard Lledo
2009-06-02 22:11         ` Andrew Morton
2009-06-03  6:09           ` Gerard Lledo
2009-06-24 10:09         ` David Woodhouse [this message]
2009-06-25  3:00           ` Andrew Morton

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=1245838141.25547.5207.camel@macbook.infradead.org \
    --to=dwmw2@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=gerard.lledo@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    /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