All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Vegard Nossum <vegard.nossum@gmail.com>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] kmemcheck: divide and conquer
Date: Mon, 16 Jun 2008 09:10:00 +0200	[thread overview]
Message-ID: <20080616071000.GA9320@elte.hu> (raw)
In-Reply-To: <19f34abd0806152355h65876c54r1ae0aa156e839db2@mail.gmail.com>


* Vegard Nossum <vegard.nossum@gmail.com> 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 <tglx@linutronix.de>
> 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.

	Ingo

  reply	other threads:[~2008-06-16  7:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-13 14:00 [RFC][PATCH] kmemcheck: divide and conquer Vegard Nossum
2008-06-14  6:31 ` Ingo Molnar
2008-06-14  8:39   ` Vegard Nossum
2008-06-14  9:00     ` Ingo Molnar
2008-06-14  9:17       ` Vegard Nossum
2008-06-16  5:15         ` Ingo Molnar
2008-06-16  6:55           ` Vegard Nossum
2008-06-16  7:10             ` Ingo Molnar [this message]
2008-06-16  7:20               ` Vegard Nossum

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=20080616071000.GA9320@elte.hu \
    --to=mingo@elte.hu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penberg@cs.helsinki.fi \
    --cc=tglx@linutronix.de \
    --cc=vegard.nossum@gmail.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.