From: Nick Piggin <npiggin@suse.de>
To: Jack Steiner <steiner@sgi.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linux Memory Management List <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: GRU driver feedback
Date: Thu, 24 Jul 2008 08:52:34 +0200 [thread overview]
Message-ID: <20080724065234.GB10972@wotan.suse.de> (raw)
In-Reply-To: <20080724032627.GA36603@sgi.com>
On Wed, Jul 23, 2008 at 10:26:28PM -0500, Jack Steiner wrote:
> On Wed, Jul 23, 2008 at 04:12:30PM +0200, Nick Piggin wrote:
> >
> > Hi Jack,
> >
> > Some review of the GRU driver. Hope it helps. Some trivial.
>
> Thanks for the feedback. I'm at OLS this week & barely reading email.
> I'll go thru the comments as soon as I get home next week & will
> respond in detail then.
OK, no problem. Andrew said he's happy to hold off the driver merge
for a bit and we should be able to drop it in post-rc1 if we can get
it sorted out.
> > - I would put all the driver into a single patch. It's a logical change,
> > and splitting them out is not really logical. Unless for example you
> > start with a minimally functional driver and build more things on it,
> > I don't think there is any point avoiding the one big patch. You have to
> > look at the whole thing to understand it properly anyway really.
>
> I would prefer that, too, but was told by one of the more verbose
> kernel developers (who will remain nameless) that I should split the code
> into multiple patches to make it easier to review. Oh well.....
I don't want to make a big stink out of it. But I don't understand
why half (or 1/5th) of a driver is a particularly good unit of change.
1. basic functionality, 2. more stuff, 3. documentation, 4. kconfig or
some such splitup seems more appropriate if it really must be split,
but IMO each change should as much as possible result in a coherent
complete source tree before and after.
Anyway, yeah, no big deal so if Andrew decided to merge them together
or leave them split, I go along with that ;)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2008-07-24 6:52 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-23 14:12 Nick Piggin
2008-07-24 2:41 ` Nick Piggin
2008-07-24 3:26 ` Jack Steiner
2008-07-24 6:52 ` Nick Piggin [this message]
2008-07-28 17:36 ` Jack Steiner
2008-07-28 17:44 ` Jack Steiner
2008-07-29 2:00 ` Nick Piggin
2008-07-29 18:53 ` Robin Holt
2008-07-30 5:50 ` Nick Piggin
2008-07-31 7:14 ` Nick Piggin
2008-07-31 12:40 ` Jack Steiner
2008-08-01 12:11 ` Hugh Dickins
2008-08-01 20:09 ` Jack Steiner
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=20080724065234.GB10972@wotan.suse.de \
--to=npiggin@suse.de \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=steiner@sgi.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