[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <19f34abd0806160020m79f021e6tf0787b17acd3ac63@mail.gmail.com>
Date: Mon, 16 Jun 2008 09:20:41 +0200
From: "Vegard Nossum" <vegard.nossum@...il.com>
To: "Ingo Molnar" <mingo@...e.hu>
Cc: "Pekka Enberg" <penberg@...helsinki.fi>,
"Thomas Gleixner" <tglx@...utronix.de>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH] kmemcheck: divide and conquer
On Mon, Jun 16, 2008 at 9:10 AM, Ingo Molnar <mingo@...e.hu> wrote:
>
> * Vegard Nossum <vegard.nossum@...il.com> wrote:
>>
>> Right now, I am reluctant to apply your fix because it means that
>> kmemcheck tree won't build as it is. In general, what's the way to
>> resolve these things? Do you have another branch, *-fixes, where these
>> fixlets can go until either of the conflicting changesets are merged
>> upstream? If so, it seems that that would be the right place for this
>> patch. Do you agree or do you have another solution? :-)
>
> yes, i solved it the following "Git way": i did a --no-commit merge of
> the tip/x86/irq tree into the tip/kmemcheck2 branch and then
> "git-cherry-pick --no-commit"-ed the fix and thus made it a part of that
> merge commit. This way the build failure is never visible during
> bisection either.
Aha. This means that I don't need to do anything but ack your fix.
Sounds good to me, thanks!
(I guess I will still need to check out -tip to find the source of the
memset redefinition warning.)
Vegard
--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036
--
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