----------------------------------------------------------------------
Date: Fri, 21 Nov 2014 15:28:30 +0400
From: Eugene Ivanov <[email protected]>

>>    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.
>
>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 behaviour. Though it would be a nice feature to be able to specify
>provider of class separately from provider of instance.

   Would LTTng-delvers more versed in these innards care to comment on the 
following?

   If the provider argument to the macros is not intended to ever point at 
anything else than the provider block it is declared in (the #define 
TRACEPOINT_PROVIDER line), this should be documented and ideally the macros 
should hide this implicit argument.

   On the other hand, if the intent is to allow cross-provider usage of some 
form, this also needs to be documented.  What is the recipe supposed to be?

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
[email protected]
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Reply via email to