LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Michael Ellerman <michael@ellerman.id.au>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Greg KH <greg@kroah.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	linux-pci@atrey.karlin.mff.cuni.cz,
	"David S. Miller" <davem@davemloft.net>,
	linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
	daniel.e.wolstenholme@intel.com
Subject: Re: [PATCH 0/21] MSI rework
Date: Mon, 26 Mar 2007 17:09:51 +1000	[thread overview]
Message-ID: <1174892991.4782.11.camel@concordia.ozlabs.ibm.com> (raw)
In-Reply-To: <m1ps705ka1.fsf@ebiederm.dsl.xmission.com>

[-- Attachment #1: Type: text/plain, Size: 3071 bytes --]

On Fri, 2007-03-23 at 04:25 -0600, Eric W. Biederman wrote:
> Michael Ellerman <michael@ellerman.id.au> writes:
> 
> > On Thu, 2007-03-22 at 15:08 -0700, Greg KH wrote:
> >> On Fri, Mar 23, 2007 at 09:02:16AM +1100, Benjamin Herrenschmidt wrote:
> >> > > > i.e.  First the simple bug fixes that should purely be restructure of
> >> > > > msi.c with no affect on anything outside of it.
> >> > > > 
> >> > > > And then get into the architecture enhancements.
> >> > > 
> >> > > I agree, care to break these down into a smaller series of patches that
> >> > > can go into -mm for testing?
> >> > 
> >> > I don't see the point in breaking the serie... you can bisect half way
> >> > through if necessary... it's made of small patches that are done, afaik,
> >> > in such a way that the whole thing should still work at any level in the
> >> > serie.
> >> > 
> >> > The serie just expresses the dependency between them.
> >> 
> >> Ok, then which patches in the series should be acceptable to take right
> >> now for 2.6.22?  The "clean up the BUG" ones?
> >
> > The series is already very verbose, I don't think I can split most of
> > them any smaller without producing an unbuildable kernel.
> 
> That wasn't the request.
> 
> > I think 1 up to and including 11 are safe as houses, they shouldn't have
> > any effect other than to clean up the code.
> >
> > The rest make functional changes, but they're all quite small, self
> > contained, and easily bisectable. I'd certainly like Eric to have a look
> > at them, but at some point I think we're just going to have to bite the
> > bullet and merge them, and see what we get in the way of bug reports.
> 
> What I wanted was the patches organized into functional groups that
> were small enough to review as a unit.  (Feed the existing patches slower
> please).
> 
> This seems to be to much change to read and review as a unit, I just get
> bleary eyed, and start to get confused.
> 
> So far I have found one subtle bug.  Where admittedly my code wasn't as
> obvious as it could be and you were proposing to use an irq that had already
> been freed.
> 
> What I had hoped we can do is you would send a handful at a time I
> would review them.  Then we could get the next handful.  I expect
> doing it that way it should take about a week to get through them all.
> 
> I guess I can try going through the review that way as well.  Pick a
> subset of what you have sent and review it very carefully, and the
> next day pick a different subset.  

OK. For starters, do you want to review the first eleven as I've sent
them already, that saves spamming everyone again.

If you're OK with those eleven, then I'll send the remaining 10 or so
later in the week, broken up into (sort-of) functional groups.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2007-03-26  7:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1174560686.307511.956605711793.qpush@cradle>
2007-03-22 15:01 ` Eric W. Biederman
2007-03-22 19:08   ` Greg KH
2007-03-22 22:02     ` Benjamin Herrenschmidt
2007-03-22 22:08       ` Greg KH
2007-03-22 22:31         ` Benjamin Herrenschmidt
2007-03-23  4:17         ` Michael Ellerman
2007-03-23 10:25           ` Eric W. Biederman
2007-03-26  7:09             ` Michael Ellerman [this message]
2007-03-26 11:52               ` Eric W. Biederman

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=1174892991.4782.11.camel@concordia.ozlabs.ibm.com \
    --to=michael@ellerman.id.au \
    --cc=akpm@osdl.org \
    --cc=benh@kernel.crashing.org \
    --cc=daniel.e.wolstenholme@intel.com \
    --cc=davem@davemloft.net \
    --cc=ebiederm@xmission.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --subject='Re: [PATCH 0/21] MSI rework' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).