[ltt-dev] [RFC] CTF TSDL: clocks and dynamic enumerations

[Mathieu Desnoyers]

Hi!

I'd like to get your opinion on the following topics: addition of clock
descriptions to the CTF TSDL and addition of dynamic enumerations
(enumerations which mapping can be updated dynamically). (see questions
below)

First, a few words about the recent changes: I changed the sequence
type, which was previously declared with e.g.:

  elem_type field_name[unsigned int];

to something more generic: instead of declaring the type of the sequence
between brackets, we declare a reference to an unsigned integer field
that needs to be located prior to the sequence (in the dynamic scope),
e.g.:

struct {
  unsigned int seqlen;
  elem_type field_name[seqlen];
  ...
}

Expressing sequences like this will let us support the gprof histogram
record format with a simple description and a convertion from size in
bits to size in bytes. By the way, anyone looking for a format to try
converting using babeltrace is welcome to contribute a plugin for it:
http://sourceware.org/binutils/docs/gprof/File-Format.html

Also, I added support for metadata in both text format and packet-based
format, which is autodetected by babeltrace by checking a magic number
for the packet-based format. The packet-based metadata is generated by
the new LTTng v2.0 kernel tracer (in development, near completion). A
major new feature of this tracer is that it becomes entirely independent
of any modification to the Linux kernel tree (this will please Linux
distributions).

I also enhanced pretty-printing of sequences and arrays of bytes when
the byte type is declared with the "encoding = UTF8 or ASCII" attribute.
Arrays and sequences of integers show up as strings in babeltrace in
that case.

* Clock description

So now about the clock description, I talked a little bit with Brian
about this. The idea is to describe the relationship between the various
time and ordering references available on a system as a simple
description in the TSDL metadata. Some ideas on how to express this
(note: the "clock {}" description is just made up as I thought it.
Feedback would be welcome)


event {
        name = timer_tick;      /* or sync_point... */
        id = 3;
        fields := {
                uint64_t monotonic_value;
                uint64_t tsc_value;
                uint32_t seqnum;
        };
};

event {
        name = freq_change;
        id = 4;
        fields := {
                uint64_t new_freq;
        };
};

clock {
        name = monotonic;
        uuid = /* some unique identifier specific to this board's clock */;
};

clock {
        name = seqnum;
        uuid = /* some unique identifier specific to this board's clock */;
};

clock {
        name = tsc;
        sync_points = {
                map {
                        parent.clock = monotonic;
                        parent.value = event.timer_tick.monotonic_value;
                        value = event.timer_tick.tsc_value;
                };
                map {
                        parent.clock = seqnum;
                        parent.value = event.timer_tick.seqnum;
                        value = event.timer_tick.tsc_value;
                };
        };

        freq = {
                update = event.freq_change.new_freq;
        };
        uuid = /* some unique identifier specific to this board's clock */;
};

* Dynamic enumerations

Currently, CTF only allows describing "static" enumerations: they have
to be declared like a C enumeration, all at once, and are valid for
their scope (they are thus invariant over the trace duration). However,
There are various resources that would need enumerations that can be
dynamically updated while the trace is being recorded, e.g. mappings of
function names to their address range (updated triggered on executable
exec/exit and library load/unload), mapping of IRQs to their handlers
(changed when devices are discovered), etc.

Ideally, the idea is to piggyback as much as possible on my existing
enum declaration. I'm thinking about having something like the following
(I don't like this semantic particularly, it's written from the top of
my head. Comments welcome.)

dynamic_enum : unsigned long {
        updated_by = {
                event = name;
                field_identifier = field_name;
                field_value_start = field_name;
                field_value_end = field_name;
        };
};

Thanks,

Mathieu


-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com