[lttng-dev] Scope of event names?

[Thibault, Daniel]

   I'm operating under the assumption that an event's "fully qualified" identifier is something like session:domain:channel:name.  Tracepoints and syscalls have system-defined names, and of course the domain can only be 'kernel' or 'userspace', but everything else is pretty much arbitrary.  My hypothesis is thus that, as long as they're in different channels (or domains or possibly sessions), two events may bear the same name even though they represent completely different occurrences.  So here's what I did (lttng list output has been abridged), with comments interspersed:

$ sudo -H lttng create asession
Session asession created.
Traces will be written in /root/lttng-traces/asession-20130214-145626
$ sudo -H lttng enable-event sched_switch -k --tracepoint
kernel event sched_switch created in channel channel0
$ sudo -H lttng enable-event sched_switch -k --function lttng_calibrate_kretprobe --channel channel1
Error: Event sched_switch: Enable kernel event failed (channel channel1, session asession)
Warning: Some command(s) went wrong
/*
 Okay, so maybe event names have session:domain scope. Let's test this.
 */
$ sudo -H lttng enable-event fevent -k --function lttng_calibrate_kretprobe --channel channel1
kernel event fevent created in channel channel1
$ sudo -H lttng enable-event fevent -k --function lttng_calibrate_kretprobe --channel channel2
kernel event fevent created in channel channel2
/*
 Apparently not.
 */
$ sudo -H lttng list asession
Tracing session asession: [inactive]
=== Domain: Kernel ===
- channel2: [enabled]
    Events:
      fevent (type: probe) [enabled]
        offset: 0x0
        symbol: lttng_calibrate_kretprobe
- channel1: [enabled]
    Events:
      fevent (type: probe) [enabled]
        offset: 0x0
        symbol: lttng_calibrate_kretprobe
- channel0: [enabled]
    Events:
      sched_switch (loglevel: TRACE_EMERG (0)) (type: tracepoint) [enabled]
/*
 Instead of tracepoint then function, let's try function then tracepoint
 */
$ sudo -H lttng enable-event sched_process_fork -k --function lttng_calibrate_kretprobe --channel channel3
kernel event sched_process_fork created in channel channel3
$ sudo -H lttng enable-event sched_process_fork -k
kernel event sched_process_fork created in channel channel0
$ sudo -H lttng enable-event sched_process_fork -k --function lttng_calibrate_kretprobe --channel channel4
Error: Event sched_process_fork: Enable kernel event failed (channel channel4, session asession)
Warning: Some command(s) went wrong
/*
 Fascinating.
 */
$ sudo -H lttng list asession
Tracing session asession: [inactive]
- channel3: [enabled]
    Events:
      sched_process_fork (type: probe) [enabled]
        offset: 0x0
        symbol: lttng_calibrate_kretprobe
- channel2: [enabled]
    Events:
      fevent (type: probe) [enabled]
        offset: 0x0
        symbol: lttng_calibrate_kretprobe
- channel1: [enabled]
    Events:
      fevent (type: probe) [enabled]
        offset: 0x0
        symbol: lttng_calibrate_kretprobe
- channel0: [enabled]
    Events:
      sched_process_fork (loglevel: TRACE_EMERG (0)) (type: tracepoint) [enabled]
      sched_switch (loglevel: TRACE_EMERG (0)) (type: tracepoint) [enabled]

   At this point it looks like defining a kernel tracepoint prevents that tracepoint's name from being used in other channels to define other events (or even the same event).  But nothing apparently prevents these other events from being set up *before* the tracepoint.  (Not shown here is the case where a tracepoint is defined in one channel, and then in another: the second tracepoint event definition fails as well)

   Can anyone shed light on this?  (Note that I haven't even tried yet to see what happens between simultaneous sessions...)

   The control flow of the error-causing commands is something like:

event.c's event_kernel_enable_tracepoint returns LTTNG_ERR_KERN_ENABLE_FAIL because
kernel.c's kernel_create_event gets something else than ENOSYS or EEXIST from
kernel-ctl.c's kernctl_create_event 

   Beyond kernctl_create_event is debugfs, inside of which occurs...whatever.

Daniel U. Thibault
R & D pour la défense Canada - Valcartier (RDDC Valcartier) / Defence R&D Canada - Valcartier (DRDC Valcartier)
Cyber sécurité pour les missions essentielles (CME) / Mission Critical Cyber Security (MCCS)
Protection des systèmes et contremesures (PSC) / Systems Protection & Countermeasures (SPC)
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/>