Greetings,
The CTF spec contains a couple of mentions of how one could define a
missing field bitmask:
"The header is extended in the rare occasions where the information cannot be
represented in the ranges available in the standard event header. They are also
used in the rare occasions where the data required for a field could not be
collected: the flag corresponding to the missing field within the missing_fields
array is then set to 1"
and
"An example of event-specific event context is to declare a bitmap of missing
fields, only appended after the stream event context if the extended event
header is selected. NR_FIELDS is the number of fields within the event (a
numeric value).
event {
context = struct {
variant <id> {
struct { } compact;
struct {
uint1_t missing_fields[NR_FIELDS]; /* missing event fields bitmap */
} extended;
} v;
};
...
}"
Is this capability reflected in the current lttng builds? My understanding so
far is that "missingness" is not part of CTF grammar per se but is rather a
convention (i.e. declaring an array of uint1_t's with a particular name
"missing_fields") -- is this correct? In the extended header example above, how
is a missing_fields slot mapped to its corresponding field -- are the fields
assumed to be ordered, with a slot per field in that ordering?
To give some context for my use case:
- I generate my own binary data and I would like to leverage TMF and/or
babeltrace to view it
- my in-memory event format is roughly <event ID> + <missing field bitmap> +
<fields that are present> (with certain alignment constraints) and I would like
to understand whether I can describe it using CTF
- in principle, I can post-process my data as needed so it fits some CTF
grammar but I simply don't quite understand how this missing fields feature
works
Any help would be much appreciated.
Thanks,
Vlad
_______________________________________________
lttng-dev mailing list
[email protected]
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
