[lkml]   [2008]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH] kmemcheck: divide and conquer

* Vegard Nossum <> wrote:

> For some reason, there is no <asm/irq_vectors.h> in my repository, so
> I assume the change came from another branch. In fact, I should have
> included <asm/hw_irq.h>, but that doesn't contain the right
> definitions in the tip/auto-test branch.
> Yep, seems to be
> commit 9b7dc567d03d74a1fbae84e88949b6a60d922d82
> Author: Thomas Gleixner <>
> Date: Fri May 2 20:10:09 2008 +0200
> x86: unify interrupt vector defines
> I also can't seem to get the redefined warnings, so I assume that's
> also just an indirect conflict with other -tip changes.
> 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.

tip/kmemcheck2 is a temporary topic tree: it contains the pull from your
tree and i'm testing it at the moment. It will be renamed to
tip/kmemcheck once it has passed testing.

btw., due to kmemcheck not being rebased anymore, this will work out
just fine in the future: i can pull fixes from your tree into
tip/kmemcheck and it will just all get sorted out by Git, despite the
cross-merge to tip/x86/irq.

If you rebased kmemcheck i'd have to do rather difficult (and
error-prone and harder to trust) manual merges every time you put a
kmemcheck fix into your tree, and any breakages introduced by new
kmemcheck fixes would not be easily bisectable either.


 \ /
  Last update: 2008-06-16 09:13    [W:0.153 / U:0.760 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site