Re: [PATCH v3 2/4] tracing: Make syscall_(un)regfunc arch-specific

From: Ingo Molnar
Date: Mon Aug 24 2009 - 04:41:37 EST



* Paul Mundt <lethal@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/