LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: michael@ellerman.id.au
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: Fri, 23 Mar 2007 04:25:26 -0600 [thread overview]
Message-ID: <m1ps705ka1.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <1174623443.5401.21.camel@concordia.ozlabs.ibm.com> (Michael Ellerman's message of "Fri, 23 Mar 2007 15:17:23 +1100")
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.
I have been sufficiently active in this code lately that I think I can
do a good review, and I want to. Unfortunately I'm only human and
a good review is nearly as much work as writing the patches myself
which means it takes time.
Eric
next prev parent reply other threads:[~2007-03-23 10:34 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 [this message]
2007-03-26 7:09 ` Michael Ellerman
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=m1ps705ka1.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=akpm@osdl.org \
--cc=benh@kernel.crashing.org \
--cc=daniel.e.wolstenholme@intel.com \
--cc=davem@davemloft.net \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=michael@ellerman.id.au \
--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).