Mathieu Desnoyers, June 2007

Marker design

Events are described in data structures in DECLARE_MARKER(), in the same file
the marker is in, or exported and in a globally included header.

When a new marker is encountered (module load, marker armed), an event_load
event is traced in the facilities channel. If the marker refers to an already
existing marker declaration, nothing changes, except that it must check that the
types match.

At trace start, we take the superset of the filtered in events and arm their
markers. We trace an event load event for each armed marker encountered.

Format string verification by GCC.

Format string extensions (sequence, structs, arrays..)

Field names.


User space tracing

Declare their own DECLARE_MARKER, use MARK() macros that refers to it. At module
load, (to decide) either the kernel or the library walks on the markers sections
and issues a marker_load  system call. Facility namespacing prefix "user_" is
used for userspace facilities.

We have to deal with multiple registrations of the same event with different
caracteristics but same name.

Markers must be enabled by the kernel, if activated and tracing starts.

Modify linker script to get section start and end in programs.


-------------------------

Maybe DECLARE_MARKER is not necessary:

Use LTTV dictionnary to add information about events.
event and field description.

<facility name="fac">
<event name="event"> <description> assdfas </description> </event>
<field name="field1"> <description> asdfasdf </description> </field>
<field name="field2"> <enum>....</enum><description> asdfasdf </description> </field>
</facility>

Field names

trace_mark(facility_event, "field1 %u field2 %p", asdf, asdf);

Extract the field names from the format string.
Check for format string equivalence before enabling a marker. Allow enabling
markers with the same format string as the first one found, but warn about the
others which do not match.
Trace an event_load event for each enabled marker with non-NULL format string at
trace start and when they are activated. Since we want to keep the same format
string if module loads/unload/reload, and we cannot point into this module's
memory, we reallocate the entry and copy the format string whenever the newly
loaded module contains active markers and these markers have a NULL format
string.
When we enable a marker, if the marker has a non null format string, we trace a
marker_load.

Default : cardinal field1, field2....
Calling: ltt_trace
callback[0]: ltt_serialize_data

Types

-- Add network byte ordering to types.
-- Change format strings to use backward compatible types. (format check)

Reserve 8 IDs for core events. Never allow wrapping over 65535 IDs during a
trace : need compaction when no trace is active.

Marker hash table points to a structure containing the marker's event ID (16
bits). Assign event ID when a probe is registered.

Compact channel. Use separate 8 bits event IDs for events going in the
compact channel. Identified by registering probe with id type MARKER_ID_COMPACT.

update probes (temp)

-- Enabling a marker:
-- give: state marker name, channel.
/proc/markers: enable/disable name [channel]

probe_data should provide, for ltt:
callbacks
id <-- will stay in marker because otherwise we would need another hash table.
channel index : put inside the marker structure (parameter to register).
A marker control module

Q: field names in dictionnary or in marker ?


What users will do with marker interface:

from userspace:
enable/disable marker_name (act on any marker, reg by module or other)
channel marker_name channel_name (act on any marker)

Default: use serializer
But.. module can override _default_ probe with a "register" operation.

Use case
Set channel
Register by specific module (unregister default, register specific)
activate.

Serve as a proxy for probe registration.