* Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > On Thu, 2009-11-26 at 08:16 +0000, tip-bot for Ingo Molnar wrote: > > Commit-ID: 091ad3658e3c76c5fb05f65bfb64a0246f8f31b5 > > Gitweb: http://git.kernel.org/tip/091ad3658e3c76c5fb05f65bfb64a0246f8f31b5 > > Author: Ingo Molnar <mingo@xxxxxxx> > > AuthorDate: Thu, 26 Nov 2009 09:04:55 +0100 > > Committer: Ingo Molnar <mingo@xxxxxxx> > > CommitDate: Thu, 26 Nov 2009 09:04:55 +0100 > > > > events: Rename TRACE_EVENT_TEMPLATE() to DECLARE_EVENT_CLASS() > > > > It is not quite obvious at first sight what TRACE_EVENT_TEMPLATE > > does: does it define an event as well beyond defining a template? > > > > To clarify this, rename it to DECLARE_EVENT_CLASS, which follows > > the various 'DECLARE_*()' idioms we already have in the kernel: > > > > DECLARE_EVENT_CLASS(class) > > > > DEFINE_EVENT(class, event1) > > DEFINE_EVENT(class, event2) > > DEFINE_EVENT(class, event3) > > > > To complete this logic we should also rename TRACE_EVENT() to: > > > > DEFINE_SINGLE_EVENT(single_event) > > > > ... but in a more quiet moment of the kernel cycle. > > > I would like to hear what others think about this change before we go > ahead and implement it. You mean TRACE_EVENT() -> DEFINE_SINGLE_EVENT()? Sure, we want todo it in a more quiet moment of the kernel cycle, not now. (TRACE_EVENT_TEMPLATE OTOH has existed for just a few days so it's not a problem.) > A lot of developers have just learned about TRACE_EVENT and now it > just disappeared. Well, not really, but in the sense of ' find > linux.git -name '*.[ch]' | xargs grep TRACE_EVENT' it no longer > exists. A second problem with the TRACE_EVENT name is that it's not just for tracing - we dont necessarily 'trace' events here. We can use the event callbacks to collect pure counts: | aldebaran> perf stat -e sched:sched_wakeup ./hackbench 10 | Time: 0.093 | | Performance counter stats for './hackbench 10': | | 15481 sched:sched_wakeup | | 0.107390574 seconds time elapsed etc. A third problem is that the name 'TRACE_EVENT' does not tell us what is being done. Do we declare it? Do we also define it? DEFINE_SINGLE_EVENT() solves all these problems: - It's obvious what it does - It suggests users of it that there's another non-single-event facility, gently nudging them towards the use of the more efficient DEFINE_EVENT_CLASS() + DEFINE_EVENT() method. - It fits nicely into the rest of the naming scheme. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|