Messages in this thread | | | From | (Eric W. Biederman) | Subject | Re: [PATCH 0/21] MSI rework | Date | Fri, 23 Mar 2007 04:25:26 -0600 |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |