From: Steven Rostedt <[email protected]>
Date: Mon, 31 Aug 2009 14:09:04 -0400 (EDT)
>
> On Mon, 31 Aug 2009, Ingo Molnar wrote:
>
>>
>> * Xiao Guangrong <[email protected]> wrote:
>>
>> > - Convert NAPI's tracepoint via TRACE_EVENT macro, the output information
>> > like below:
>>
>> I think as long as it does not touch tracing infrastructure (which
>> your patches dont do in their current form) this should be
>> done/merged via the networking tree.
>
> I agree, all changes that are in include/trace/events/ and trace point
> usage can stay within the subsystem tree.
>
>>
>> [ There might be some small collisions in define_trace.h (because
>> these tracepoints move from legacy to new-style TRACE_EVENT()
>> form) but that's OK. ]
>
> But changes to anything in include/trace or kernel/trace needs to go
> throught the tracing subsystem. This includes a changes to define_trace.h.
This patch can't be split up, so I'm wondering how you suggest to
handle this patch given that you have declared that define_trace.h
changes aren't to go through the subsystem tree?
If we do the define_trace.h change only, we break the build
(lack of macro defined for the trace).
If we do only the other parts of his patch, we get a duplicate
definition.
And keep in mind that Neil and Xiao are probably going to want to do
work on top of this to the networking bits. Thus if we put this patch
here into the tracing tree, I'll have to develop a dependency on the
tracing tree and I think that will go over like a fart in a spacesuit
with the -next crowd and Stephen Rothwell in particular.
Please advise.
David Miller wrote:
> This patch can't be split up, so I'm wondering how you suggest to
> handle this patch given that you have declared that define_trace.h
> changes aren't to go through the subsystem tree?
>
> If we do the define_trace.h change only, we break the build
> (lack of macro defined for the trace).
>
> If we do only the other parts of his patch, we get a duplicate
> definition.
>
This patch cooperate with my previous patch to solve the include file
dependencies problem. So, we do better put those two patches together.
(both in -tip tree or/add both in network tree)
The previous patch is below:
Commit-ID: 5ac35daa9343936038a3c9c4f4d6d3fe6a2a7bd8
Gitweb: http://git.kernel.org/tip/5ac35daa9343936038a3c9c4f4d6d3fe6a2a7bd8
Author: Xiao Guangrong <[email protected]>
AuthorDate: Tue, 25 Aug 2009 14:06:22 +0800
Committer: Steven Rostedt <[email protected]>
CommitDate: Wed, 26 Aug 2009 00:32:09 -0400
tracing/events: fix the include file dependencies
> And keep in mind that Neil and Xiao are probably going to want to do
> work on top of this to the networking bits. Thus if we put this patch
> here into the tracing tree, I'll have to develop a dependency on the
> tracing tree and I think that will go over like a fart in a spacesuit
> with the -next crowd and Stephen Rothwell in particular.
>
Thank you, David
Xiao
* Xiao Guangrong <[email protected]> wrote:
> David Miller wrote:
>
> > This patch can't be split up, so I'm wondering how you suggest to
> > handle this patch given that you have declared that define_trace.h
> > changes aren't to go through the subsystem tree?
> >
> > If we do the define_trace.h change only, we break the build
> > (lack of macro defined for the trace).
> >
> > If we do only the other parts of his patch, we get a duplicate
> > definition.
> >
>
> This patch cooperate with my previous patch to solve the include
> file dependencies problem. So, we do better put those two patches
> together. (both in -tip tree or/add both in network tree)
I would not mind a duplicate commit here. Whoever merges later in
the merge window will resolve the (easy) conflict.
David, you definitely dont want to pull the full tracing tree into
the networking tree. It wouldnt cause technical problems in
linux-next (Git sorts out such merges just fine and both trees are
well tested) but it creates an unwanted merge window dependency: if
the tracing tree's push to Linus is delayed for whatever reason the
networking tree is delayed too. That's not really good.
It's also not good on a conceptual angle - it makes it very
difficult for Linus to reject any of the trees, due to the mingling.
A second variant would be that we could create a mini-topic (.31-rc8
based) in -tip with just the skb bits and the header file changes
and once we've tested it we could push it and you could pull that
(small, -git based) tree into the networking tree.
A third variant would be that you could do such a mini-topic branch
yourself in the networking tree and we could pull that into the
tracing tree.
All of these variants work fine with Steve's and my workload, it's
up to you and Neil - you are driving the changes so do whatever is
most convenient to you.
Ingo