public inbox for linux-next@vger.kernel.org 
 help / color / mirror / Atom feed
* linux-next: manual merge of the tracing tree with the parisc tree
@ 2009-04-01  0:37 Stephen Rothwell
  2009-04-01  6:54 ` Uwe Kleine-König
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Stephen Rothwell @ 2009-04-01  0:37 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin
  Cc: linux-next, Helge Deller, Kyle McMartin, linux-parisc,
	Uwe Kleine-Koenig, Steven Rostedt

[-- Attachment #1: Type: text/plain, Size: 552 bytes --]

Hi all,

Today's linux-next merge of the tracing tree got a conflict in
arch/parisc/include/asm/ftrace.h between commit
d75f054a2cf0614ff63d534ff21ca8eaab41e713 ("parisc: add ftrace (function
and graph tracer) functionality") from the parisc tree and commit
c79a61f55773d2519fd0525bf58385f7d20752d3 ("tracing: make CALLER_ADDRx
overwriteable") from the tracing tree.

The former adds a non-trivial version of the file, so I used that.
-- 
Cheers,
Stephen Rothwell                    sfr@canb•auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: linux-next: manual merge of the tracing tree with the parisc tree
  2009-04-01  0:37 linux-next: manual merge of the tracing tree with the parisc tree Stephen Rothwell
@ 2009-04-01  6:54 ` Uwe Kleine-König
  2009-04-01 11:05 ` Ingo Molnar
  2009-04-01 17:50 ` Kyle McMartin
  2 siblings, 0 replies; 10+ messages in thread
From: Uwe Kleine-König @ 2009-04-01  6:54 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, linux-next,
	Helge Deller, Kyle McMartin, linux-parisc, Steven Rostedt

Hi Steven,

On Wed, Apr 01, 2009 at 11:37:40AM +1100, Stephen Rothwell wrote:
> Today's linux-next merge of the tracing tree got a conflict in
> arch/parisc/include/asm/ftrace.h between commit
> d75f054a2cf0614ff63d534ff21ca8eaab41e713 ("parisc: add ftrace (function
> and graph tracer) functionality") from the parisc tree and commit
> c79a61f55773d2519fd0525bf58385f7d20752d3 ("tracing: make CALLER_ADDRx
> overwriteable") from the tracing tree.
Whatever you have done---I didn't check---as long as
arch/parisc/include/asm/ftrace.h exists, it's OK for
c79a61f55773d2519fd0525bf58385f7d20752d3.

Best regards and thanks
Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-König            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: linux-next: manual merge of the tracing tree with the parisc tree
  2009-04-01  0:37 linux-next: manual merge of the tracing tree with the parisc tree Stephen Rothwell
  2009-04-01  6:54 ` Uwe Kleine-König
@ 2009-04-01 11:05 ` Ingo Molnar
  2009-04-01 11:10   ` Uwe Kleine-König
  2009-04-01 17:50 ` Kyle McMartin
  2 siblings, 1 reply; 10+ messages in thread
From: Ingo Molnar @ 2009-04-01 11:05 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, H. Peter Anvin, linux-next, Helge Deller,
	Kyle McMartin, linux-parisc, Uwe Kleine-Koenig, Steven Rostedt


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

> Hi all,
> 
> Today's linux-next merge of the tracing tree got a conflict in
> arch/parisc/include/asm/ftrace.h between commit
> d75f054a2cf0614ff63d534ff21ca8eaab41e713 ("parisc: add ftrace (function
> and graph tracer) functionality") from the parisc tree and commit
> c79a61f55773d2519fd0525bf58385f7d20752d3 ("tracing: make CALLER_ADDRx
> overwriteable") from the tracing tree.
> 
> The former adds a non-trivial version of the file, so I used that.

You need to be careful, the two trees likely cannot be combined like 
that, ftrace will likely stop working on parisc because you combine 
old-parisc with new-ftrace.

If the two trees are integrated without forward-porting the parisc 
ftrace port to the new facilities, then it's safer to do a trivial 
patch that disables the ftrace bits on parisc.

	Ingo

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: linux-next: manual merge of the tracing tree with the parisc tree
  2009-04-01 11:05 ` Ingo Molnar
@ 2009-04-01 11:10   ` Uwe Kleine-König
  2009-04-01 11:19     ` Ingo Molnar
  0 siblings, 1 reply; 10+ messages in thread
From: Uwe Kleine-König @ 2009-04-01 11:10 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Stephen Rothwell, Thomas Gleixner, H. Peter Anvin, linux-next,
	Helge Deller, Kyle McMartin, linux-parisc, Steven Rostedt

Hello Ingo,

On Wed, Apr 01, 2009 at 01:05:12PM +0200, Ingo Molnar wrote:
> 
> * Stephen Rothwell <sfr@canb•auug.org.au> wrote:
> 
> > Hi all,
> > 
> > Today's linux-next merge of the tracing tree got a conflict in
> > arch/parisc/include/asm/ftrace.h between commit
> > d75f054a2cf0614ff63d534ff21ca8eaab41e713 ("parisc: add ftrace (function
> > and graph tracer) functionality") from the parisc tree and commit
> > c79a61f55773d2519fd0525bf58385f7d20752d3 ("tracing: make CALLER_ADDRx
> > overwriteable") from the tracing tree.
> > 
> > The former adds a non-trivial version of the file, so I used that.
> 
> You need to be careful, the two trees likely cannot be combined like 
> that, ftrace will likely stop working on parisc because you combine 
> old-parisc with new-ftrace.
> 
> If the two trees are integrated without forward-porting the parisc 
> ftrace port to the new facilities, then it's safer to do a trivial 
> patch that disables the ftrace bits on parisc.
I'm not sure that they really conflict.  My change ("tracing: make
CALLER_ADDRx overwriteable") only created the empty include file that I
can unconditionally include <asm/ftrace.h>.

But I don't know for sure.

Best regards
Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-König            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: linux-next: manual merge of the tracing tree with the parisc tree
  2009-04-01 11:10   ` Uwe Kleine-König
@ 2009-04-01 11:19     ` Ingo Molnar
  0 siblings, 0 replies; 10+ messages in thread
From: Ingo Molnar @ 2009-04-01 11:19 UTC (permalink / raw)
  To: Uwe Kleine-König
  Cc: Stephen Rothwell, Thomas Gleixner, H. Peter Anvin, linux-next,
	Helge Deller, Kyle McMartin, linux-parisc, Steven Rostedt


* Uwe Kleine-König <u.kleine-koenig@pengutronix•de> wrote:

> Hello Ingo,
> 
> On Wed, Apr 01, 2009 at 01:05:12PM +0200, Ingo Molnar wrote:
> > 
> > * Stephen Rothwell <sfr@canb•auug.org.au> wrote:
> > 
> > > Hi all,
> > > 
> > > Today's linux-next merge of the tracing tree got a conflict in
> > > arch/parisc/include/asm/ftrace.h between commit
> > > d75f054a2cf0614ff63d534ff21ca8eaab41e713 ("parisc: add ftrace (function
> > > and graph tracer) functionality") from the parisc tree and commit
> > > c79a61f55773d2519fd0525bf58385f7d20752d3 ("tracing: make CALLER_ADDRx
> > > overwriteable") from the tracing tree.
> > > 
> > > The former adds a non-trivial version of the file, so I used that.
> > 
> > You need to be careful, the two trees likely cannot be combined like 
> > that, ftrace will likely stop working on parisc because you combine 
> > old-parisc with new-ftrace.
> > 
> > If the two trees are integrated without forward-porting the parisc 
> > ftrace port to the new facilities, then it's safer to do a trivial 
> > patch that disables the ftrace bits on parisc.
>
> I'm not sure that they really conflict.  My change ("tracing: make 
> CALLER_ADDRx overwriteable") only created the empty include file 
> that I can unconditionally include <asm/ftrace.h>.

I know, that commit is not a problem. It just exposed the problem 
that these trees got combined in linux-next.

	Ingo

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: linux-next: manual merge of the tracing tree with the parisc tree
  2009-04-01  0:37 linux-next: manual merge of the tracing tree with the parisc tree Stephen Rothwell
  2009-04-01  6:54 ` Uwe Kleine-König
  2009-04-01 11:05 ` Ingo Molnar
@ 2009-04-01 17:50 ` Kyle McMartin
  2009-04-02 11:32   ` Stephen Rothwell
  2 siblings, 1 reply; 10+ messages in thread
From: Kyle McMartin @ 2009-04-01 17:50 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, linux-next,
	Helge Deller, Kyle McMartin, linux-parisc, Uwe Kleine-Koenig,
	Steven Rostedt

On Wed, Apr 01, 2009 at 11:37:40AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the tracing tree got a conflict in
> arch/parisc/include/asm/ftrace.h between commit
> d75f054a2cf0614ff63d534ff21ca8eaab41e713 ("parisc: add ftrace (function
> and graph tracer) functionality") from the parisc tree and commit
> c79a61f55773d2519fd0525bf58385f7d20752d3 ("tracing: make CALLER_ADDRx
> overwriteable") from the tracing tree.
> 
> The former adds a non-trivial version of the file, so I used that.
>

Thanks Stephen,

What's the optimal way to sort out multiple branches in this tree?
Apparently Andrew is cross with me because the rtc-parisc branch didn't
get picked up... Should I put a list of branches in my kernel.org
public_html or something?

r, Kyle

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: linux-next: manual merge of the tracing tree with the parisc tree
  2009-04-01 17:50 ` Kyle McMartin
@ 2009-04-02 11:32   ` Stephen Rothwell
  2009-04-02 13:54     ` James Bottomley
  2009-04-03 14:15     ` Ingo Molnar
  0 siblings, 2 replies; 10+ messages in thread
From: Stephen Rothwell @ 2009-04-02 11:32 UTC (permalink / raw)
  To: Kyle McMartin
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, linux-next,
	Helge Deller, linux-parisc, Uwe Kleine-Koenig, Steven Rostedt

[-- Attachment #1: Type: text/plain, Size: 619 bytes --]

Hi Kyle,

On Wed, 1 Apr 2009 13:50:34 -0400 Kyle McMartin <kyle@mcmartin•ca> wrote:
>
> What's the optimal way to sort out multiple branches in this tree?
> Apparently Andrew is cross with me because the rtc-parisc branch didn't
> get picked up... Should I put a list of branches in my kernel.org
> public_html or something?

I am not quite sure what you are getting at.  If you have multiple trees
(or branches in a tree), I can merge them separately into linux-next -
just tell me what they are.

-- 
Cheers,
Stephen Rothwell                    sfr@canb•auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: linux-next: manual merge of the tracing tree with the parisc tree
  2009-04-02 11:32   ` Stephen Rothwell
@ 2009-04-02 13:54     ` James Bottomley
  2009-04-02 15:22       ` Kyle McMartin
  2009-04-03 14:15     ` Ingo Molnar
  1 sibling, 1 reply; 10+ messages in thread
From: James Bottomley @ 2009-04-02 13:54 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Kyle McMartin, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	linux-next, Helge Deller, linux-parisc, Uwe Kleine-Koenig,
	Steven Rostedt

On Thu, 2009-04-02 at 22:32 +1100, Stephen Rothwell wrote:
> Hi Kyle,
> 
> On Wed, 1 Apr 2009 13:50:34 -0400 Kyle McMartin <kyle@mcmartin•ca> wrote:
> >
> > What's the optimal way to sort out multiple branches in this tree?
> > Apparently Andrew is cross with me because the rtc-parisc branch didn't
> > get picked up... Should I put a list of branches in my kernel.org
> > public_html or something?
> 
> I am not quite sure what you are getting at.  If you have multiple trees
> (or branches in a tree), I can merge them separately into linux-next -
> just tell me what they are.

Actually, the traditional way for a multi branch tree (something like
Jens' Block tree) which contains all manner of branches, some of which
are experimental and shouldn't be in linux-next, is to have a next
branch into which you manually merge all branches that should be
included.

James



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: linux-next: manual merge of the tracing tree with the parisc tree
  2009-04-02 13:54     ` James Bottomley
@ 2009-04-02 15:22       ` Kyle McMartin
  0 siblings, 0 replies; 10+ messages in thread
From: Kyle McMartin @ 2009-04-02 15:22 UTC (permalink / raw)
  To: James Bottomley
  Cc: Stephen Rothwell, Kyle McMartin, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, linux-next, Helge Deller, linux-parisc,
	Uwe Kleine-Koenig, Steven Rostedt

On Thu, Apr 02, 2009 at 01:54:43PM +0000, James Bottomley wrote:
> Actually, the traditional way for a multi branch tree (something like
> Jens' Block tree) which contains all manner of branches, some of which
> are experimental and shouldn't be in linux-next, is to have a next
> branch into which you manually merge all branches that should be
> included.
> 
> James
> 

Heh, that makes sense. Occam's Razor, I guess.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: linux-next: manual merge of the tracing tree with the parisc tree
  2009-04-02 11:32   ` Stephen Rothwell
  2009-04-02 13:54     ` James Bottomley
@ 2009-04-03 14:15     ` Ingo Molnar
  1 sibling, 0 replies; 10+ messages in thread
From: Ingo Molnar @ 2009-04-03 14:15 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Kyle McMartin, Thomas Gleixner, H. Peter Anvin, linux-next,
	Helge Deller, linux-parisc, Uwe Kleine-Koenig, Steven Rostedt,
	linux-kernel


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

> Hi Kyle,
> 
> On Wed, 1 Apr 2009 13:50:34 -0400 Kyle McMartin <kyle@mcmartin•ca> wrote:
> >
> > What's the optimal way to sort out multiple branches in this 
> > tree? Apparently Andrew is cross with me because the rtc-parisc 
> > branch didn't get picked up... Should I put a list of branches 
> > in my kernel.org public_html or something?
> 
> I am not quite sure what you are getting at.  If you have multiple 
> trees (or branches in a tree), I can merge them separately into 
> linux-next - just tell me what they are.

One solution, when there are lots of branches, is what we use in the 
-tip tree to auto-integrate the auto-*-next output branches.

It works like this:

For each output auto-*-next tree (there's 19 at the moment) there's 
a special file under the tip:tip/.tip/auto-branches/ directory.

Say the auto-tracing-next tree is represented via a list of topic 
branches in .tip/auto-branches/auto-tracing-next:

    tracing/core
    tracing/urgent
    tracing/ftrace
    tracing/mmiotrace
    tracing/sysprof
    tracing/nmisafe
    tracing/stack-tracer
    tracing/fastboot
    tracing/markers
    tracing/ring-buffer
    tracing/pipe
    tracing/tracepoints
    tracing/core-v2
    tracing/fastboot-v2
    tracing/core-v3
    tracing/function-return-tracer
    tracing/branch-tracer
    
    # dont know yet:
    # tracing/dump-tracer
    
    tracing/options
    tracing/profiling
    tracing/power-tracer
    tracing/powerpc

    # broken right now:
    # tracing/hw-branch-tracing

    tracing/function-graph-tracer
    tracing/blktrace
    tracing/graph-tracer
    tracing/docs
    tracing/kmemtrace
    tracing/kmemtrace2
    tracing/printk
    tracing/doc
    tracing/syscalls
    tracing/syscalls
    tracing/filters
    tracing/tasks
    tracing/kprobes
    tracing/hw-breakpoints
    tracing/blktrace-v2
    tracing/kmemtrace-v2

When things are quiet and there are no known regressions, i type:

  tip-integrate auto-tracing-next

and soon afterwards a new tree comes out. I dont have to do any 
manual integration, it's all automated, including the cached 
resolution of conflicts. If a new conflict comes up i get a shell 
prompt, fix the conflict, commit it and the integration continues.

If i'm happy with the end result i push it out.

As you can see it above, branches can be annotated and commented 
out. For example this branch:

    # broken right now:
    #tracing/hw-branch-tracing

was causing boot crashes so we excluded it from the 
auto-tracing-next output and linux-next wont crash due to these 
known and under-development problems.

Another branch:

    # dont know yet:
    # tracing/dump-tracer

Is holding commits i'm not sure we want to push upstream yet, so we 
dont push it into linux-next. (linux-next is meant for items that 
are intended for the next cycle.)

There's a similar list of topics for the other integration trees:

 auto-core-next         auto-latest                     auto-stackprotector-next
 auto-cpus4096-next     auto-oprofile-next              auto-timers-next
 auto-fastboot-next     auto-perfcounters-next          auto-tracing-next
 auto-generic-ipi-next  auto-rt-next                    auto-warnings-next
 auto-genirq-next       auto-safe-poison-pointers-next  auto-x86-next
 auto-iommu-next        auto-sched-next
 auto-kmemcheck-next    auto-sparseirq-next

Over 100 topic branches are active typically just before the merge 
window - they go down to below 10 after the merge window. So there's 
a constant ebb and flow in topic activity.

We also have a "tip-integrate-all" script that runs through all the 
-next branches and integrates them.

These tools can be found under the -tip:.tip/bin/ directory - 
there's currently 68 utility scripts there currently, to solve 
various probems all around integration tree maintenance, problems 
which are often not solved by the base Git toolset adequately.

Hope this helps,

	Ingo

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2009-04-03 14:15 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-04-01  0:37 linux-next: manual merge of the tracing tree with the parisc tree Stephen Rothwell
2009-04-01  6:54 ` Uwe Kleine-König
2009-04-01 11:05 ` Ingo Molnar
2009-04-01 11:10   ` Uwe Kleine-König
2009-04-01 11:19     ` Ingo Molnar
2009-04-01 17:50 ` Kyle McMartin
2009-04-02 11:32   ` Stephen Rothwell
2009-04-02 13:54     ` James Bottomley
2009-04-02 15:22       ` Kyle McMartin
2009-04-03 14:15     ` Ingo Molnar

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