[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200801181734.51193.ak@suse.de>
Date: Fri, 18 Jan 2008 17:34:51 +0100
From: Andi Kleen <ak@...e.de>
To: Ingo Molnar <mingo@...e.hu>
Cc: linux-kernel@...r.kernel.org, tglx@...utronix.de,
jbeulich@...ell.com, venkatesh.pallipadi@...el.com
Subject: Re: CPA boot crash (was: [PATCH] [0/36] Great change_page_attr patch series v3)
On Friday 18 January 2008 17:21:18 Ingo Molnar wrote:
>
> * Andi Kleen <ak@...e.de> wrote:
>
> > > > (except for the white space changes, but that can be redone once
> > > > everything settled down again). Then it will be bisectable.
> > >
> > > it's a revert barrier (within v2.6.25),
> >
> > What is a revert barrier?
> >
> > Anyways of course the way to handle that is the same as with the other
> > undo patches: drop the original white space changes
> > (ddb53b5735793a19dc17bcd98b050f672f) completely and then drop that
> > undo patch too. The white space changes haven't reached Linus yet so
> > you can just make them disappear completely from known history.
>
> we dont want them to disappear, due to the second half of:
>
> http://lkml.org/lkml/2008/1/18/112
<reads the new gospel>
> we want easy-cleanups first, difficult changes applied second. It's a
> well-established concept.
That rule of thumb makes sense if someone does a series from scratch, but
redoing a large existing series just because someone else sneaked in a white space
patch at the wrong time does not seem to be very efficient to me.
After all these rules are not to make our lives more complicated,
but to to make things more efficient.
And most of the code in the white space cleanup changes anyways in the later
CPA series.
And what is left you'll get them again anyways once the CPA stuff is
in and people tested it a bit more so it has settled down.
I promise to redo them on top of the end result.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists