[lttng-dev] Question about TRACEPOINT_EVENT_CLASS and TRACEPOINT_EVENT_INSTANCE

[Eugene Ivanov]

Thanks for the explanation, Daniel! Unfortunately using class defined in
another provider doesn't work. I get an error about undefined
__event_probe__instance_provider_name___class_name_from_another_provider’.
Connecting it with your description, I guess it's probably a feature and
 intended behavior. Though it would be a nice feature to be able to specify
provider of class separately from provider of instance.

On Wed, Nov 19, 2014 at 9:14 PM, Thibault, Daniel <
Daniel.Thibault at drdc-rddc.gc.ca> wrote:

> > Date: Wed, 19 Nov 2014 15:35:01 +0400
> > From: Eugene Ivanov <eiva at tbricks.com>
> >
> > I found description of TRACEPOINT_EVENT_CLASS on the website and in
> ust-tracepoint-event.h as well, but it is not documented in the lttng-ust
> man page.
> > According the header TRACEPOINT_EVENT_INSTANCE declares an instance of a
> tracepoint, with its own provider and name.
> > Does it mean that I can define classes for usage in different providers?
> Why do we need provider in _CLASS then?
> > According the code on the first glance it seems that it is required that
> CLASS and INSTANCE must share in same provider.
>
>    You will also have seen that the "default" macro TRACEPOINT_EVENT
> simply wraps both TRACEPOINT_EVENT_CLASS and TRACEPOINT_EVENT_INSTANCE
> together.  When used separately, the TRACEPOINT_EVENT_INSTANCE must match
> its template's params; the event class then takes care of the mapping of
> parameters to fields in the event output.  This allows you to declare a
> single event class somewhere, then declare various instances that vary by
> name only, typically because they're events of the same nature but
> occurring in varying contexts.  Having the trace label them under different
> names makes the analyst's life easier.
>
>    Normally you use TRACEPOINT_EVENT_CLASS and _INSTANCE within the same
> provider, but you could theoretically have varying instances rely on
> different providers.  I guess this would allow you some flexibility in
> picking which sets of instances to enable/disable by picking which provider
> shared objects (.so) to preload or not.
>
>    Kernel space has essentially the same macros under the names
> DECLARE_EVENT_CLASS and TRACE_EVENT, respectively.  You can see those at
> work in the lttng-modules package and in some kernel modules such as
> drivers/staging/android/binder_trace.h.  In the latter, for example, you
> see a binder_lock_class which is then instantiated as binder_lock,
> binder_locked, and binder_unlock.  These three events carry very different
> semantics, but they have precisely the same parameter signatures.  Grouping
> them under an event class avoids a lot of cutting-and-pasting and
> diminishes the risk of errors later on (e.g. if you had to modify the field
> layout of binder_lock and forgot to copy it to binder_unlock).
>
>    "Why do we need provider in _CLASS then?"  Because the provider name is
> part of the fully-qualified event class name.  This allows different event
> classes (and event instances) to have the same short names within different
> providers.  You would be bound to run into collisions if all the event
> class or event instance names were global.
>
> Daniel U. Thibault
> Protection des systèmes et contremesures (PSC) | Systems Protection &
> Countermeasures (SPC)
> Cyber sécurité pour les missions essentielles (CME) | Mission Critical
> Cyber Security (MCCS)
> RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research
> Centre
> 2459 route de la Bravoure
> Québec QC  G3J 1X5
> CANADA
> Vox : (418) 844-4000 x4245
> Fax : (418) 844-4538
> NAC : 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ>
> Gouvernement du Canada | Government of Canada
> <http://www.valcartier.drdc-rddc.gc.ca/>
>
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>



-- 
Eugene
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20141121/b411bf70/attachment-0001.html>