[ Adding to Cc everyone that now has a broken tree thanks to this .. ] On Wed, Aug 12, 2009 at 11:11:33AM +0200, Ingo Molnar wrote: > * Frederic Weisbecker <fweisbec@xxxxxxxxx> wrote: > > This pull request integrate one cleanup/fix for ftrace and an > > update for syscall tracing: the migration from old-style tracer to > > individual tracepoints/trace_events and the support for perf > > counter. > > > > I've tested it with success either with ftrace (every syscall > > tracepoints enabled at the same time without problems) and with > > perfcounter. > > > > May be one drawback: it creates so much trace events that the > > ftrace selftests can take some time :-) > > Pulled, thanks a lot! > And this has now subsequently broken every single SH and S390 configuration, and anyone else unfortunate enough to be supporting ftrace syscall tracing that isn't x86, without so much as a Cc, well done! The s390 case can be fixed up in-tree as support has already been merged, but in the SH case we had ftrace syscall tracing queued up for 2.6.32, so it doesn't show up in -tip, but the end result in -next is now completely broken. I'm not sure how we should handle this, if tracing/core in -tip isn't rebased, should I just pull the topic-branch in to my tree, fix up the sh support on top of that, and push the end result out? This seems like the easiest option at least, but I don't know what other dependencies exist for tracing/core. Alternative suggestions welcome. This happens again and again with ftrace and -tip, where people just randomly change existing interfaces, break all of the existing users, and then fail to tell anyone about it until it shows up in -next. Even if we had pushed all of the sh ftrace bits to the -tip tree early on it would not have changed anything, evident by the fact that s390 and all of the non ftrace syscall architectures were broken by this change as well (the latter case was at least caught and corrected, although not by the original authors of this patch series). Is it really that much to task that people who are running around breaking ftrace interfaces actually bother to Cc the architectures that are using it? If -tip is going to perpetuate this sort of half-assed development methodology, it has no place in -next. -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
