public inbox for linux-next@vger.kernel.org 
 help / color / mirror / Atom feed

From: Ingo Molnar <mingo@elte•hu>
To: Stephen Rothwell <sfr@canb•auug.org.au>
Cc: Thomas Gleixner <tglx@linutronix•de>,
	"H. Peter Anvin" <hpa@zytor•com>,
	linux-next@vger•kernel.org,
	James Bottomley <James.Bottomley@HansenPartnership•com>
Subject: Re: linux-next: manual merge of the tip-core tree with Linus' tree
Date: Fri, 6 Feb 2009 14:53:49 +0100	[thread overview]
Message-ID: <20090206135349.GB3415@elte.hu> (raw)
In-Reply-To: <20090206132601.b207fb0e.sfr@canb.auug.org.au>


* Stephen Rothwell <sfr@canb•auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next merge of the tip-core tree got a conflict in
> arch/x86/mach-voyager/voyager_smp.c between commit
> 92ab78315c638515d0e81b0c70b2082f713582d9 ("x86/Voyager: make it build and
> boot") from Linus' tree and commit
> 552be871e67ff577ed36beb2f53d078b42304739 ("x86: pass in cpu number to
> switch_to_new_gdt()") from the tip-core tree.
> 
> I used the resolution from tip/master (see below -worth checking that I 
> got it right).  (Though I assume that there is no reason that the other 
> uses of smp_processor_id() in voyager_smp_prepare_boot_cpu could be 
> replaced by "cpu" as well?)

Thanks!

Note that the x86/Voyager code will have to be totally reworked ontop of the 
new x86 subarch code and that the cpumask logic there is largely obsolete 
(in the context of linux-next) and cannot be triggered via any 
Kconfig-reachable build mode anymore.

I've pushed out a next tip/auto-core-next branch so the conflict should 
disappear from your tree.

Note that there's another upcoming conflict, in arch/x86/mm/fault.c, due to 
this upstream commit from a few hours ago:

  9be260a: prevent kprobes from catching spurious page faults

This will conflict both with the pagefault cleanups in tip/x86/mm and with 
tip/kmemcheck so it's a non-trivial 3-way conflict. I've resolved the 
conflicts explicitly on the Git level and pushed out a freshly integrated 
x86-next, core-next and kmemcheck-next tree as well - so you should not be 
seeing conflicts in that area.

Note: take care because these trees also contain a lot of new stuff: the x86 
APIC and subarch rewrite, the shiny new percpu changes and cleanup and more. 
Let us know if you run into any trouble with them.

Thanks,

	Ingo

next prev parent reply	other threads:[~2009-02-06 13:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-06  2:26 linux-next: manual merge of the tip-core tree with Linus' tree Stephen Rothwell
2009-02-06 13:53 ` Ingo Molnar [this message]
  -- strict thread matches above, loose matches on Subject: below --
2009-05-21  1:39 Stephen Rothwell
2009-05-21  3:56 ` Darren Hart
2009-05-21  9:30   ` Thomas Gleixner
2009-05-21  9:38     ` Stephen Rothwell
2009-05-22  0:19   ` Stephen Rothwell
2009-05-22  5:50     ` Stephen Rothwell
2009-05-22 18:18       ` Darren Hart
2009-04-06  0:36 Stephen Rothwell
2009-02-09  0:38 Stephen Rothwell
2009-02-09  0:46 ` Chris Mason
2009-02-09  8:51   ` Ingo Molnar
2009-02-02  0:46 Stephen Rothwell

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=20090206135349.GB3415@elte.hu \
    --to=mingo@elte$(echo .)hu \
    --cc=James.Bottomley@HansenPartnership$(echo .)com \
    --cc=hpa@zytor$(echo .)com \
    --cc=linux-next@vger$(echo .)kernel.org \
    --cc=sfr@canb$(echo .)auug.org.au \
    --cc=tglx@linutronix$(echo .)de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox