Date:	Mon, 24 Aug 2009 10:41:01 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Paul Mundt <lethal@...ux-sh.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Josh Stone <jistone@...hat.com>, linux-kernel@...r.kernel.org,
	Jason Baron <jbaron@...hat.com>,
	Li Zefan <lizf@...fujitsu.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Jiaying Zhang <jiayingz@...gle.com>,
	Martin Bligh <mbligh@...gle.com>,
	Lai Jiangshan <laijs@...fujitsu.com>
Subject: Re: [PATCH v3 2/4] tracing: Make syscall_(un)regfunc arch-specific


* Paul Mundt <lethal@...ux-sh.org> wrote:

> On Sun, Aug 23, 2009 at 11:14:24PM +0200, Frederic Weisbecker wrote:
> > On Fri, Aug 21, 2009 at 09:58:43PM -0700, Josh Stone wrote:
> > > The bodies of syscall_regfunc and syscall_unregfunc need the
> > > arch-specific flag TIF_SYSCALL_TRACEPOINT, which only exists
> > > on x86 and s390, so they should live in arch-specific files.
> > 
> > Sh also does, but currently in a seperate development branch. 
> > (Adding Paul Mundt in Cc to prevent from further linux-next 
> > breakage).
> 
> Thanks, I'll take care of this as well as the other ftrace 
> syscalls breakage during the merge window. At the moment I don't 
> have any good ideas on how to fix the workflow issues, and -tip 
> likewise doesn't care about -next impact, so there's somewhat of 
> an impasse.

Where did you take the nonsense from that '-tip likewise doesn't 
care about -next impact'? It's a false statement on several levels.

The thing is, there is just a single 'breakage' here (SH does not 
build if the tracing tree is mixed with the SH tree), and you 
inflicted it upon yourself: you mixed ftrace development into the SH 
tree (thinking that the syscall-tracing facility was a stable API - 
where did _that_ nonsense come from?), while the tracing tree did 
development of ftrace too (surprise), so when the two versions were 
mixed in linux-next it broke.

There's numerous ways to resolve this and i'm willing to help out 
with any of the solutions your chose (or with some other variant if 
it makes sense):

 - Easiest: you can turn off the old-API based ftrace bits in the SH 
   tree, in your for-next branch. This is the easiest, but keeps new 
   SH ftrace bits untested in linux-next.

 - Most conservative route: you wait with your new bits until the 
   new tracing facilities hit upstream in the merge window. The
   disadvantage is that this delays your code and there's no 
   guarantee that it cannot collide with new changes.

 - The proper workflow: you can actually help out the development of 
   tracing facilities by doing tracing development in the tracing 
   tree. We merged a number of architecture ftrace improvements via 
   the tracing tree already, as long as it's acked by the maintainer 
   (which is a given here - you maintain SH) and as long as it does 
   not touch non-ftrace bits of the architecture unreasonably.

   This is the most natural workflow and the fastest one as well. 
   The ftrace bits are well separated (or should be well separated). 
   We didnt do ftrace development via the x86 tree either.

I'd favor the third one as it's the most intelligent variant and we 
used that in a number of other cases - but it's up to you.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists