* Steven Rostedt (rostedt@xxxxxxxxxxx) wrote: > On Wed, 2009-12-02 at 11:27 -0500, Mathieu Desnoyers wrote: > > > A few questions about the semantic: > > > > Is "declare" here always only used as a declaration ? (e.g. only in > > headers, never impacted by CREATE_TRACE_POINT ?) > > Well yes it is impacted by CREATE_TRACE_POINT, but so is DECLARE_TRACE > for that matter ;-) > > The difference is that DECLARE_EVENT_CLASS will at most (with > CREATE_TRACE_POINT) only create the functions that can be used by other > events. It does not create an event itself. That is, it's not much > different than making a "static inline function" except that function > will not be static nor will it be inline ;-) > > > > > Is "define" here always mapping to a definition ? (e.g. to be used in a > > C file to define the class or event handling stub) > > The DEFINE_* will create something that can be hooked to the trace > points in other C files. > > > > > > I feel that your DEFINE_EVENT_CLASS might actually be doing a bit more > > than just "defining", it would actually also perform the declaration. > > Same goes for "DEFINE_EVENT". So can you tell us a bit more about that > > is the context of templates ? > > > Well, the macros used by these are totally off the wall anyway :-) So > any name we come up with will not match what the rest of the kernel does > regardless. But we need to give something that is close. > > I'm liking more the: > > DECLARE_EVENT_CLASS, DEFINE_EVENT, DEFINE_EVENT_CLASS, because I think > that comes the closest to other semantics in the kernel. That is (once > again) > > DECLARE_EVENT_CLASS - makes only the class. It does create helper > functions, but if there's no DEFINE_EVENT that uses them, then they are > just wasting space. > > The DEFINE_EVENT will create the trace points in the C file that has > CREATE_TRACE_POINTS defined. But it requires the helper functions > created by a previous DECLARE_EVENT_CLASS. > > DEFINE_EVENT_CLASS will do both create a EVENT_CLASS template, as well > as a EVENT that uses the class. The name of the class is a separate > namespace as the event. Here both the class and the event have the same > name, but other events can use this class by referencing the name. > > DEFINE_EVENT_CLASS(x, ...); > > DEFINE_EVENT(x, y, ...); > > The DEFINE_EVENT_CLASS will create a class x and an event x, then the > DEFINE_EVENT will create another event y that uses the same class x. > > > Actually, with the above, we may not need to have DECLARE_EVENT_CLASS() > at all, because why declare a class if you don't have an event to use > it? But then again, you may not want the name of the class also a name > of an event. Hrm. I wonder if having DEFINE_EVENT_CLASS is really worth having, considering that it really just does 2 things at once and may be confusing. I would have thought amongst the lines of the following as main API (note: "SKETCH" is only a proposal. The idea is to do _not_ use declare/define, as it's really something _different_ than what people are expecting!) SKETCH_EVENT_CLASS() SKETCH_EVENT() Which would use only DECLARE, or both DECLARE and DEFINE depending if CREATE_TRACE_POINTS is set. I see the DECLARE/DEFINE more as the "low-level" macros that are actually selected by CREATE_TRACE_POINTS: DECLARE_EVENT_CLASS : only performs event class declarations (macros, inlines...) DECLARE_EVENT : only performs event instance declarations (macros, inlines, ...). Depends on the DECLARE_EVENT_CLASS(). DEFINE_EVENT_CLASS : create instances of template functions. DEFINE_EVENT : create event tracepoint functions. Depends on DEFINE_EVENT_CLASS(). This way, it should make digging into the generation system internals headhache-free. ;) I think we should really avoid re-using terms people are familiar with for things that have a semantic intrincially different than what people come to expect. Mathieu > > -- Steve > > -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 -- 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
|