On Wed, 2010-09-22 at 14:15 -0400, Steven Rostedt wrote: > On Wed, 2010-09-22 at 19:30 +0200, Peter Zijlstra wrote: > > On Wed, 2010-09-22 at 10:06 -0700, Arjan van de Ven wrote: > > > > > That said, I really didn't read this discussion much, but your stance > > seems to be that any tracepoint you use must stay valid, and I object to > > that. > > We could add a TRACE_EVENT_ABI() as Ingo has been suggesting. If > anything, it could mean that the given tracepoint will always have the > same name. And perhaps the data it holds will always be there, but may > also be extended. I still don't see why you need TRACE_EVENT_ABI for that, if its the same name and the format can be extended you get the same results with what we've got. Apps need to read/parse the format thing anyway. > > > > What will do you do when we include a new scheduling policy and all the > > scheduler tracepoints need to change? (yes that's really going to > > happen) > > The tracepoint sched_switch should stay the same. We may add more data, > but the comm, pid, prio => comm, pid, prio, I don't see going away. Right, it would need additional fields. Preferably not only at the end. > > I'm not going to carry double tracepoints, and I'm not going to not > > merge that policy. > > Not sure what you mean by "double tracepoints" Two different tracepoints in the same location. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
