Philippe Proulx [Fri, 1 Mar 2019 02:17:00 +0000 (21:17 -0500)]
Fix: cli: cmd_list_plugins(): pass appropriate by-index functions
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Fri, 1 Mar 2019 02:16:29 +0000 (21:16 -0500)]
Fix: lib: `_const_const` -> `_const`
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Fri, 1 Mar 2019 01:17:48 +0000 (20:17 -0500)]
sink.text.pretty: "discarded a number of X" -> "might have discarded X"
I believe this is a better wording.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Wed, 27 Feb 2019 19:16:51 +0000 (14:16 -0500)]
lib: iterator auto-seeking: handle intersecting discarded items messages
This patch makes the message iterator auto-seeking algorithm handle
discarded events and packets messages of which the seeking time
intersects the message's time range, for example:
discarded events
msg
v |
===*=========*=*===|==*== * * *
^ event msg |
^ seeking time
In this scenario, we obviously don't want to keep the three event
messages which occur before the seeking time, but we want to keep a part
of the discarded events message because discarding it entirely (as it
was done before this patch) leads to information loss, i.e.:
|
| * * * *
|
Instead, when this happens, we set the discarded events/packets
message's beginning time to the seeking time, make its count
unavailable, and we keep the message:
|
|==*== * * *
|
The message iterator's internal auto-seeking message array is replaced
with a message queue as there can be more messages in this queue than
the iterator's message array capacity now. Because of this, the
post-seeking temporary "next" method fills the output message array as
long as messages exist in the auto-seeking message queue. When the
message queue is finally empty, it resets the iterator's "next" method
to the original user method.
Because setting a discarded items message's beginning time to a seeking
time (in nanoseconds from origin) requires a conversion from nanoseconds
from origin to a raw clock value, the internal
bt_clock_class_clock_value_from_ns_from_origin() utility is added. This
function can fail if there's an overflow in arithmetic operations.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Francis Deslauriers [Sat, 23 Feb 2019 00:53:15 +0000 (19:53 -0500)]
lib: create a clock class object from component
Before this commit, a trace class was needed for the creation of a clock
class. Turns out that clock class may be needed before the creation any
trace class. For example, Inactivity messages created before a trace has
generated any data need a clock class but no trace class was created yet.
This commit allows for the creation of clock classes even when no trace
classes exist using a component class.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Francis Deslauriers [Tue, 19 Feb 2019 21:12:16 +0000 (16:12 -0500)]
lib: rename inactivity msg to msg iterator inactivity msg
This is avoid confusion with stream activity message types.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Francis Deslauriers [Tue, 19 Feb 2019 20:08:26 +0000 (15:08 -0500)]
lib: Pass raw snapshot value to bt_message_inactivity_create()
Having both
bt_message_inactivity_create(bt_self_message_iterator *message_iterator,
const bt_clock_class *default_clock_class);
and
bt_message_inactivity_set_default_clock_snapshot(
bt_message *msg, uint64_t raw_value);
is redundant given that setting the clock snapshot value is required to
send the inactivity message down the graph.
This commit makes it so that the value of the snapshot is required at
the creation of the inactivity message.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Philippe Proulx [Thu, 21 Feb 2019 22:12:11 +0000 (17:12 -0500)]
lib: add sink component class's "graph is configured" method
All filter component classes implement the same logic currently to
support their instance being connected input first or output first.
Before this patch, if a filter component was connected to a sink
component, the sink component's "input port connected" method was called
and this is where the sink component had to create an input port message
iterator. This made the filter message iterator initialize, but it was
possible that the filter's input ports were not connected yet. To
support this connection order, the filter message iterator had to add
itself to a list of iterators within the component's private data, and
upstream iterators had to be initialized when the filter component's
"input port connected" method was called. Also, when the filter message
iterator was finalized, it had to remove itself from the component's
list. This strategy worked, but it was cumbersome and did lead to
duplicated code amongst different filters.
This patch does the following:
* It makes the graph have two phases: configuration and
post-configuration. The configuration phase is when you create and
connect components. The post-configuration is as soon as you call
bt_graph_run(), bt_graph_consume(), or
bt_port_output_message_iterator_create().
* It makes it incorrect (validated in developer mode) to create an input
port message iterator during the graph's configuration phase. In other
words, an "input port connected" method cannot call
bt_self_component_port_input_message_iterator_create() anymore.
* It adds an optional sink component class's "graph is configured"
method. This method is considered to be called when the graph is
configured (post-configuration phase): it is called at the beginning
of bt_graph_run() or bt_graph_consume() when it was not previously
called.
This is where a sink can call
bt_self_component_port_input_message_iterator_create() now. This leads
to a chain of message iterator initialization which all occur during
the post-configuration phase. This guarantees to the initialization
methods that ports are connected, and that disconnected ports will
never be connected.
This is not a big change for sink component classes, if any: for the
`sink.text.pretty`, `sink.utils.counter`, and `sink.utils.dummy`
component classes, the "input port connected" method is simply replaced
with the "graph is configured" method.
This is however a big change for filter component classes. For example,
the `flt.utils.muxer` component class is much simpler as of this patch:
it simply creates all its upstream message iterators in its message
iterator initialization method, and hundreds of lines of codes are
removed.
Checking that the graph is configured at the beginning of
bt_graph_consume() could potentially have a performance impact, but I
did not measure this. If it's the case, then we would need a dedicated
graph function, for example bt_graph_confirm_configuration(), to call
the "graph is configured" methods once before calling bt_graph_consume()
in a loop.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Thu, 21 Feb 2019 21:29:11 +0000 (16:29 -0500)]
Fix: lib-logging.c: use temporary prefix where needed
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Wed, 20 Feb 2019 19:30:50 +0000 (14:30 -0500)]
lib: rename clock class's absolute property to "origin is Unix epoch"
This is simply straightforward and describes precisely what the absolute
property used to mean.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Tue, 19 Feb 2019 19:51:02 +0000 (14:51 -0500)]
Fix: flt.utils.muxer: make sure message's default clock class exists
Without the checks added by this patch, the iterator can borrow the
default clock snapshot of a message related to a stream class without
any default clock class. This is a precondition break.
If there's no default clock class, then we fall back to assuming this
message has the same time as the latest returned message's time.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Tue, 19 Feb 2019 19:50:34 +0000 (14:50 -0500)]
sink.text.pretty: use fast clock class access
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Tue, 19 Feb 2019 18:56:37 +0000 (13:56 -0500)]
lib: message API: add fast default clock class accessors
This patch adds a few
bt_message_X_borrow_stream_class_default_clock_class() functions to
quickly get the default clock class of a message's stream class.
It is a library precondition that a message's stream class has a default
clock class in order to borrow its default clock snapshot. This is
because, sometimes, a default clock snapshot object exists even if it's
never used for pooling and allocation reasons. There's no conditional in
the clock snapshot borrowing functions for performance reasons, so you
can't rely on the clock snapshot output parameter being `NULL` or not.
The correct way to know whether or not there's a default clock snapshot
to check if the message's stream class has a default clock class, which
you can now do in a single call.
For example, before:
const bt_message *event_msg = ...;
const bt_event *event = bt_message_event_borrow_event_const(event_msg);
const bt_packet *packet = bt_event_borrow_packet_const(event);
const bt_stream *stream = bt_packet_borrow_stream_const(event);
const bt_stream_class *stream_class =
bt_stream_borrow_class_const(stream);
const bt_clock_class *def_clock_class =
bt_stream_class_borrow_default_clock_class_const(stream_class);
if (def_clock_class) {
/* safe to borrow message's default clock snapshot */
}
Now:
const bt_message *event_msg = ...;
const bt_clock_class *def_clock_class =
bt_message_event_borrow_stream_class_default_clock_class_const(
event_msg);
if (def_clock_class) {
/* safe to borrow message's default clock snapshot */
}
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Tue, 19 Feb 2019 18:34:25 +0000 (13:34 -0500)]
flt.utils.muxer: implement "seek beginning" and "can seek beginning" methods
The `flt.utils.muxer` "can seek beginning" method returns the logical
conjunction of all the upstream message iterators's "can seek beginning"
results.
The `flt.utils.muxer` "seek beginning" method performs a "seek
beginning" operation on all its upstream message iterators.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Tue, 19 Feb 2019 16:59:26 +0000 (11:59 -0500)]
src.text.dmesg: implement "seek beginning" and "can seek beginning" methods
It is possible to make a `src.text.dmesg` message iterator seek its
beginning when it's reading a file, not the standard input. Its "can
seek beginning" method indicates this.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Tue, 19 Feb 2019 16:45:42 +0000 (11:45 -0500)]
src.ctf.fs: implement "seek beginning" method
This message iterator method resets the `src.ctf.fs` iterator's current
index within the file group and the stream decoder.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Tue, 19 Feb 2019 16:05:01 +0000 (11:05 -0500)]
src.text.dmesg: make clock class non-absolute
The `dmesg` command's timestamps are not absolute; they are relative to
the boot time.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Tue, 19 Feb 2019 14:40:16 +0000 (09:40 -0500)]
iterator.c: auto-seeking: use packet messages's clock snapshots
Consider the default clock snapshots of packet beginning and end
messages in get_message_ns_from_origin() for auto-seeking.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Tue, 19 Feb 2019 14:29:22 +0000 (09:29 -0500)]
flt.utils.muxer: handle all message types specifically
The get_msg_ts_ns() function in `muxer.c` was only handling event and
inactivity messages, making all other messages high priority by default.
However, other messages can have default clock snapshots too, so they
can be sorted.
For discarded events and packets, we use the beginning clock snapshot
as, for the same stream, it must be greater than or equal to the
previous message's clock snapshot (if any), and less than or equal to
the next message's clock snapshot, if any.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Tue, 19 Feb 2019 14:27:43 +0000 (09:27 -0500)]
Update `include/babeltrace/babeltrace.h`
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Tue, 19 Feb 2019 14:27:28 +0000 (09:27 -0500)]
include/Makefile.am: add missing files
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Tue, 19 Feb 2019 14:20:53 +0000 (09:20 -0500)]
lib-logging.c: log event, packet beginnin/end message clock snapshot
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Tue, 19 Feb 2019 14:17:55 +0000 (09:17 -0500)]
Fix some include directives (add missing, remove superfluous)
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Tue, 19 Feb 2019 14:14:55 +0000 (09:14 -0500)]
lib: have default clock snapshot in event message
The event message is the only message not having a default clock
snapshot property (it's in an event object). Since an event object is
unique and belongs solely to an event message, make it more consistent
and move the default clock snapshot property to the message instead.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Mon, 18 Feb 2019 23:14:27 +0000 (18:14 -0500)]
assert-pre-internal.h: append "error is" to first message
The previous message, "Library precondition not satisfied", was
misleading because the following message does not indicate the
precondition, but how the precondition was not satisfied.
Making it "Library precondition not satisfied; error is:" here to make
it clear that the following message indicates what the error is.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Mon, 18 Feb 2019 23:09:59 +0000 (18:09 -0500)]
discarded-items.c: add clock class's existence precondition assertion
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Mon, 18 Feb 2019 23:01:02 +0000 (18:01 -0500)]
lib: add default clock snapshot property to packet beginning/end message
Packet beginning/end clock snapshot properties were removed from the
`bt_packet` object in a previous commit because they were considered
redundant with the time ranges given by the recently added discarded
events/packets messages.
Now it seems that those properties are needed in order for a message
iterator such as `flt.utils.trimmer` to know whether or not a given
packet beginning/end message is within a given time range. This removes
uncertainty for a class of filters and sinks.
The CTF format has a concept of packet with a specific end time in its
context, but not all source formats have this chance. For this reason,
instead of putting the beginning and end clock snapshot properties in
the `bt_packet` object itself, which would require any source to know
its packet's end time in advance, the packet beginning/end message
itself contains the property. For example, in this patch,
`src.text.dmesg` is modified to set the first event's clock snapshot as
the single packet beginning message's clock snapshot, and the last
event's clock snapshot as the single packet end message's clock
snapshot. Similar sources should take this approach, as those fields are
mandatory if the message's packet's stream's class has a registered
default clock class.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Fri, 15 Feb 2019 20:14:32 +0000 (15:14 -0500)]
Fix: src.text.dmesg: put leaking trace class on component destruction
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Fri, 15 Feb 2019 20:14:15 +0000 (15:14 -0500)]
src.text.dmesg: emit stream activity beginning/end messages
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Fri, 15 Feb 2019 19:48:26 +0000 (14:48 -0500)]
lib: remove redundant `bt_packet` properties
Those properties can be accessed in another way using newly introduced
messages:
* Stream activity beginning
* Stream activity end
* Discarded events
* Discarded packets
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Thu, 14 Feb 2019 23:49:49 +0000 (18:49 -0500)]
sink.text.pretty: print warning message on discarded events/packets message
This patch enables the discarded events/packets warning messages printed
to the standard error stream again. They are now based on discarded
events/packets messages.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Thu, 14 Feb 2019 23:12:34 +0000 (18:12 -0500)]
src.ctf.fs: emit discarded events/packets messages
Make a `src.ctf.fs` message iterator emit appropriate discarded events
and packets messages when needed. For the moment the information is
redundant with the equivalent counters within `bt_packet` objects, but
those will be removed eventually before 2.0-rc1.
To avoid getting a discarded packets message (therefore a warning with
`sink.text.pretty`) for any partial trace, like it's the case with LTTng
snapshots, it is not emitted when a stream's first packet's sequence
number is not 0.
However, if the stream's first packet's discarded event counter is
greater than 0, a discarded events message is emitted, indicating an
unknown number of discarded events between the packet's beginning time
and the packet's end time. I believe this is the best approximation we
can get for this exceptional scenario.
I refactored some states of `msg-iter.c`, adding states dedicated to
check if we have to emit or not some types of messages. Emitting or not
stream beginning/end and stream activity beginning/end messages is
handled by such states now: for example,
check_emit_msg_stream_beginning_state() sets the current state to
`STATE_EMIT_MSG_STREAM_BEGINNING` or
`STATE_CHECK_EMIT_MSG_DISCARDED_EVENTS` depending on how
bt_msg_iter_set_emit_stream_beginning_message() was called the last
time. This makes bt_msg_iter_get_next_message() unconditionally create
messages when getting emitting states, as some are completely skipped by
the checking states. The `STATE_CHECK_EMIT_MSG_DISCARDED_EVENTS` checks
whether or not a discarded events message must be emitted, and
`STATE_CHECK_EMIT_MSG_DISCARDED_PACKETS` checks whether or not a
discarded packets message must be emitted.
Before a packet beginning message, a discarded events message can be
emitted, and then a discarded packets message can be emitted, in this
order.
As of this patch, all other component classes ignore those messages.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Wed, 13 Feb 2019 23:13:00 +0000 (18:13 -0500)]
src.ctf.fs: emit stream activity beginning/end messages
Emit the newly introduced stream activity beginning/end messages from
`src.ctf.fs`.
With CTF 1.8, there is no way to know the true beginning and end times
of a stream's activity. We cannot rely on the first packet's beginning
time and the last packet's end time because this is not what they mean:
they are, in fact, used to find the time ranges of the discarded events
and packets.
I'm adding (internal) bt_msg_iter_set_emit_stream_beginning_message()
and bt_msg_iter_set_emit_stream_end_message() which control whether or
not the stream and stream activity beginning messages, and the stream
and stream activity end messages are emitted. This is used to support
more easily and efficiently multiple files per data stream: beginning
messages are enabled for the first stream file and end messages are
enabled for the last stream file.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Wed, 13 Feb 2019 18:34:03 +0000 (13:34 -0500)]
lib: iterator.c: auto-seek: handle new message types
When reading the time of a given message for auto-seeking purposes:
* Skip packet beginning/end messages as packet object beginning/end time
properties are about to be removed.
* Use a stream activity beginning time if known, otherwise skip the
message for infinite and unknown times.
* Use a stream activity end time if known, otherwise skip the message
for an unknown time (a positive infinite time is always greater than
any requested time).
* Use the beginning time of a discarded events/packets message because
this beginning time must be greater than or equal to the previous
message's time for the same stream.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Wed, 13 Feb 2019 17:13:26 +0000 (12:13 -0500)]
Make parent parameters const for some object creation functions
The goal of this patch is for a filter message iterator to be able to
create new messages with existing streams, packets, or clock classes
(not created by itself). This can be used to replace an original message
by a similar one, but slightly different.
One use case is `flt.utils.trimmer` which potentially needs to remove
original stream activity beginning/end messages and insert its own ones
to represent the trimming time range. `flt.utils.trimmer` also needs to
change the beginning and end times of discarded events/packets messages,
which it can do now by creating new messages using the original stream.
We cannot apply this to something like bt_stream_create() (making the
stream class and trace parameters const) because a stream has a parent
(trace object), therefore clashes could exist if any filter can add a
new stream to a trace which it did not create. Events, packets, and
messages have no parent.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Mon, 11 Feb 2019 21:25:45 +0000 (16:25 -0500)]
lib: add discarded packets message
This patch implements the "discarded packets" message API. You can
create such a message to communicate that packets were discarded at the
source level.
This message conveys redundant information considering the "packet
counter" property of a packet object. However, this property will be
removed before 2.0-rc1, and the discarded packet message will be the
only way to indicate discarded packets. The rationale behind this is
that the beginning and end times of the packet object do not represent a
stream activity time range (this is indicated by stream activity
beginning and end messages now); they are used for discarded event and
packet counter time ranges (when using multiple packets). To make this
less confusing, discarded events and packets are their own messages. For
the time being, both the properties and the messages coexist.
There are two ways to create a discarded packets message:
bt_message_discarded_packets_create():
Create a message using a stream of which the class has no default
clock class. This indicates that a number of packets were discarded
at this point within the message flow.
bt_message_discarded_packets_create_with_default_clock_snapshots():
Create a message using a stream of which the class has a default
clock class. In this case, you must pass the beginning and end clock
snapshot raw values which delimit the time range when packets were
discarded by the tracer.
Within the message flow, the beginning time must be greater than or
equal to the previous message's time (depending on its type). The
end time must be less than or equal to the next message's time. For
example, the `ctf` plugin sources will push such a message following
a packet end message, and the time range will be said packet end
message's packet's end time to the next packet's beginning time.
In the message flow, you can only insert this message, for a given
stream:
* Between packet end and packet beginning messages.
* Before the first packet beginning message.
* After the last packet end message.
In other words, you cannot insert this message in the middle of a
packet.
By default, the message indicates that "a number" of packets were
discarded. In other words, bt_message_discarded_packets_get_count()
returns `BT_PROPERTY_AVAILABILITY_NOT_AVAILABLE`. To be more accurate,
use bt_message_discarded_packets_set_count() to set a specific discarded
packet count.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Mon, 11 Feb 2019 20:54:47 +0000 (15:54 -0500)]
lib: add discarded events message
This patch implements the "discarded events" message API. You can create
such a message to communicate that events were discarded at the source
level.
This message conveys redundant information considering the "discarded
event counter" property of a packet object. However, this property will
be removed before 2.0-rc1, and the discarded event message will be the
only way to indicate discarded events. The rationale behind this is that
the beginning and end times of the packet object do not represent a
stream activity time range (this is indicated by stream activity
beginning and end messages now); they are used for discarded event and
packet counter time ranges (when using multiple packets). To make this
less confusing, discarded events and packets are or will be their own
messages. For the time being, both the properties and the messages
coexist.
There are two ways to create a discarded events message:
bt_message_discarded_events_create():
Create a message using a stream of which the class has no default
clock class. This indicates that a number of events were discarded
at this point within the message flow.
bt_message_discarded_events_create_with_default_clock_snapshots():
Create a message using a stream of which the class has a default
clock class. In this case, you must pass the beginning and end clock
snapshot raw values which delimit the time range when events were
discarded by the tracer.
Within the message flow, the beginning time must be greater than or
equal to the previous message's time (depending on its type). The
end time can be greater than the next message's time. For example,
the `ctf` plugin sources will push such a message following a packet
end message, and the time range will be said packet end message's
packet's end time to the next packet's end time.
By default, the message indicates that "a number" of events were
discarded. In other words, bt_message_discarded_events_get_count()
returns `BT_PROPERTY_AVAILABILITY_NOT_AVAILABLE`. To be more accurate,
use bt_message_discarded_events_set_count() to set a specific discarded
event count.
The implementation deals with "discarded items" message objects because
the same code will be used to implement the discarded packets message
API.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Mon, 11 Feb 2019 20:01:36 +0000 (15:01 -0500)]
lib: set clock snapshot member to `NULL` after bt_clock_snapshot_recycle()
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Fri, 8 Feb 2019 22:36:38 +0000 (17:36 -0500)]
lib: add stream activity beginning/end messages
Those new messages are meant to indicate the beginning and end of the
activity of a given stream, with optional clock snapshots. Eventually
all stream messages except stream beginning/end messages must be
"between" stream activity beginning and end messages.
The purpose of such messages is to indicate where tracing activity
starts and stops, for example when the LTTng `start` and `stop` commands
are executed (not supported by LTTng as of this date). This information
can be important for some filters and sinks to acknowledge the real
beginning and end of a stream, for example:
[------------############################------#######-------------]
^ stream activity beginning stream activity end ^
^^^^^^^^^^^^ tracing, but no activity ^^^^^^ ^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^ activity
We also plan to make flt.utils.trimmer remove those messages for a given
stream and "inject" its own stream activity messages to emulate a
potentially reduced stream activity, depending on the message
intersection between the requested time range to keep and the stream's
time range.
You can use the following functions to set the message's default
clock snapshot:
* bt_message_stream_activity_beginning_set_default_clock_snapshot()
* bt_message_stream_activity_end_set_default_clock_snapshot()
and borrow it with:
* bt_message_stream_activity_beginning_borrow_default_clock_snapshot_const()
* bt_message_stream_activity_end_borrow_default_clock_snapshot_const()
The message's stream's class must have a defined default clock class in
order to use the setting functions.
When you set a stream activity message's default clock snapshot, the
clock snapshot's state within this message is
`BT_MESSAGE_STREAM_ACTIVITY_CLOCK_SNAPSHOT_STATE_KNOWN`. The other
possible states are:
`BT_MESSAGE_STREAM_ACTIVITY_CLOCK_SNAPSHOT_STATE_UNKNOWN` (default):
It is not possible to know the exact time of this stream activity
message at the source level.
`BT_MESSAGE_STREAM_ACTIVITY_CLOCK_SNAPSHOT_STATE_INFINITE`:
The stream is considered to have always existed (for a stream
activity beginning message) or to exist forever (for a stream
activity end message).
A stream activity message with such a default clock snapshot state
must either immediately follow a stream beginning message or
immediately precede a stream end message.
You can set an explicit default clock snapshot state with:
* bt_message_stream_activity_beginning_set_default_clock_snapshot_state()
* bt_message_stream_activity_end_set_default_clock_snapshot_state()
bt_message_stream_activity_beginning_borrow_default_clock_snapshot_const()
and bt_message_stream_activity_end_borrow_default_clock_snapshot_const()
return the default clock snapshot's state.
Also in this patch: refactor the packet beginning/end and stream
beginning/end messages to avoid code duplication, and put the functions
in their own header file.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Thu, 7 Feb 2019 18:47:02 +0000 (13:47 -0500)]
lib: remove CV snapshot property from stream beginning/end message
The beginning and end times of a given stream will be given by another
type of message implemented in a subsequent patch.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Wed, 16 Jan 2019 22:19:14 +0000 (17:19 -0500)]
lib: add seeking (beginning, ns from origin), with auto-seeking support
This patch adds seeking support to the message iterator API. Two seeking
operations are supported:
Seek beginning:
The message iterator goes back to the beginning, that is, to its
first message (which is probably a "stream beginning" message).
Seek nanoseconds from origin:
The message iterator seeks a message which has a default clock
snapshot which is at least the requested value when converted to
nanoseconds from epoch.
No clock class is involved in this operation, only a plain value in
nanoseconds from an origin (which can be negative), to support
seeking through an iterator chain with multiple clock classes
involved. What a message iterator should do exactly is left to the
implementation for more flexibility.
A source or filter component class can have four new optional message
iterator methods:
Can seek beginning:
Returns whether or not it is possible for this iterator to seek its
beginning.
If not set, the corresponding API functions
(bt_self_component_port_input_message_iterator_can_seek_beginning()
and bt_port_output_message_iterator_can_seek_beginning()) return:
* `BT_TRUE` if the "seek beginning" method (see below) is set.
* `BT_FALSE` otherwise.
Can seek nanoseconds from origin:
Returns whether or not it is possible for this iterator to seek a
given nanosecond from origin.
If not set, the corresponding API functions
(bt_self_component_port_input_message_iterator_can_seek_ns_from_origin()
and bt_port_output_message_iterator_can_seek_ns_from_origin())
return:
* `BT_TRUE` if the "seek nanoseconds from origin" method (see below)
is set, or if
bt_self_component_port_input_message_iterator_can_seek_beginning()
returns `BT_TRUE` (auto-seeking, see below).
* `BT_FALSE` otherwise.
Seek beginning:
Seeks this iterator to its beginning.
The corresponding API functions are
bt_self_component_port_input_message_iterator_seek_beginning() and
bt_port_output_message_iterator_seek_beginning().
Seek nanoseconds from origin:
Seeks this iterator to a specific nanosecond from origin.
The corresponding API functions are
bt_self_component_port_input_message_iterator_seek_ns_from_origin()
and bt_port_output_message_iterator_seek_ns_from_origin().
If not set, then if
bt_self_component_port_input_message_iterator_can_seek_beginning()
returns `BT_TRUE` (which means it is possible for this iterator to
seek its beginning) for this iterator, then auto-seeking is enabled
for this iterator.
Auto-seeking is a feature which makes the library use only the "seek
beginning" method of an iterator to implement a "seek nanoseconds from
origin" method which calls the iterator's "next" method, skipping
messages until it finds one which matches the requested value. This
exists because most of the time it is easier for a plugin developer to
reset an iterator's state to the beginning than to seek a message having
a specific clock snapshot value.
With the conditions described above:
* If you implement the "seek beginning" method, it is the equivalent of
also implementing a "can seek beginning" method which always returns
`BT_TRUE`.
* If you implement the "seek nanoseconds from origin" method, it is the
equivalent of also implementing a "can seek nanoseconds from origin"
method which always returns `BT_TRUE`.
* If you only implement the "seek beginning" method, than the iterator's
user can always seek beginning and any nanosecond from origin.
* If you implement none of the above methods, then seeking is completely
disabled.
The methods, as well as the corresponding API functions, can return the
following message iterator statuses:
`BT_SELF_MESSAGE_ITERATOR_STATUS_OK`:
The seeking operation succeeded.
This is the only status which allows a subsequent call to the
iterator's "next" method.
`BT_SELF_MESSAGE_ITERATOR_STATUS_AGAIN`:
The seeking operation did not terminate, but this is not an error:
the iterator's user should seek again later (the same time or
a different time, for example you can seek beginning after getting
this status from seeking a specific nanosecond from origin).
`BT_SELF_MESSAGE_ITERATOR_STATUS_ERROR`:
`BT_SELF_MESSAGE_ITERATOR_STATUS_NOMEM`:
The seeking operation failed: the iterator's user must seek again
(with success) in order to make the iterator active again (able to
advance).
The seeking methods cannot return `BT_SELF_MESSAGE_ITERATOR_STATUS_END`:
if seeking reaches the end, then the seeking method must return
`BT_SELF_MESSAGE_ITERATOR_STATUS_OK` and the following call to its
"next" method must return `BT_SELF_MESSAGE_ITERATOR_STATUS_END`.
After a successful seeking operation, the first message of the batch
that an iterator's "next" method returns can be of ANY type. Therefore,
an iterator's user must have its state ready when seeking because the
usual guarantees do not need to be satisfied (for example, getting a
"packet beginning" message before any event message).
Because seeking breaks the concept of having contiguous messages with no
interruption, the concept of a message's sequence number for developer
mode validation is removed. We need to find another way to make this
validation in the future.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Thu, 20 Dec 2018 13:40:39 +0000 (08:40 -0500)]
lib: fully configure graph (add components, connect ports), then run
This patch makes the graph API force you to completely configure the
graph, that is, add components and connect their ports, before you run
it. When you run it, the graph is considered fully configured, and at
this point you cannot add components or connect ports.
This also means that components cannot remove or disconnect their own
ports anymore. Therefore all the disconnection and port removal
listeners and notifiers are removed.
The purpose of this change is to make seeking possible for all message
iterators. If a component can remove and add ports at will, considering
that message iterators are completely independent, then seeking
backwards is impossible without a scandalous hack because some message
iterators are gone for good and cannot be created again since the ports
do not exist anymore.
This change implies that a `src.ctf.lttng-live` component will need to
merge its messages itself to offer a single port on which you can create
a single message iterator. If the LTTng live protocol supports seeking
in the future, then, with a single port, the message iterator has total
control to recreate old messages which belong to already ended streams.
Note that this could apply to other, similar component classes as well.
Offering a single stream per port is possible when the number of streams
is known at component initialization time, which is the case for
`src.ctf.fs`.
`flt.utils.muxer` still adds a new input port on port connection, but
this is all done before we call bt_graph_run(), which marks the graph as
being completely configured.
An output port message iterator marks its graph as being configured
as soon as you call bt_port_output_message_iterator_next(), because you
don't call bt_graph_run() in this situation.
A graph's "configured" state is only set and checked in developer mode.
New preconditions are:
bt_self_component_port_input_message_iterator_next():
The graph is fully configured.
bt_graph_add_source_component():
bt_graph_add_source_component_with_init_method_data():
bt_graph_add_filter_component():
bt_graph_add_filter_component_with_init_method_data():
bt_graph_add_sink_component():
bt_graph_add_sink_component_with_init_method_data():
bt_graph_connect_ports():
bt_self_component_source_add_output_port():
bt_self_component_filter_add_output_port():
bt_self_component_filter_add_input_port():
bt_self_component_sink_add_input_port():
The graph is not fully configured.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Francis Deslauriers [Tue, 18 Dec 2018 21:24:25 +0000 (16:24 -0500)]
Fix: ctf plugin: returning bt_message_iterator_status from src.ctf.fs
A source should only be dealing with `bt_self_message_iterator_status`
since it's the one producing the messages.
Non-self message iterator status are received from upstream iterators
which sources have none by definition.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Francis Deslauriers [Tue, 18 Dec 2018 21:02:57 +0000 (16:02 -0500)]
Cleanup: use ctf_scope_string function to print `enum ctf_scope` vars
This fixes the following Clang warning:
ctf-meta-resolve.c:278:28: error: implicit conversion from enumeration type 'enum ctf_scope' to different enumeration type 'enum bt_scope' [-Werror,-Wenum-conversion]
bt_common_scope_string(scope));
~~~~~~~~~~~~~~~~~~~~~~ ^~~~~
../../../../include/babeltrace/logging-internal.h:854:46: note: expanded from macro 'BT_LOGV'
BT_LOG_WRITE(BT_LOG_VERBOSE, _BT_LOG_TAG, __VA_ARGS__)
^~~~~~~~~~~
../../../../include/babeltrace/logging-internal.h:818:18: note: expanded from macro 'BT_LOG_WRITE'
lvl, tag, __VA_ARGS__); \
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Francis Deslauriers [Tue, 18 Dec 2018 20:54:21 +0000 (15:54 -0500)]
Cleanup: explicitly assigning value of variable to itself
This fixes the following warning on Clang:
visitor-generate-ir.c:3487:17: error: explicitly assigning value of variable of type 'struct ctf_stream_class *' to itself [-Werror,-Wself-assign]
stream_class = stream_class;
~~~~~~~~~~~~ ^ ~~~~~~~~~~~~
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Francis Deslauriers [Tue, 18 Dec 2018 20:47:20 +0000 (15:47 -0500)]
Fix: may be used uninitialized trace_name variable
This fixes the following Clang warning:
dmesg.c:263:7: error: variable 'trace_name' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
if (strcmp(basename, G_DIR_SEPARATOR_S) != 0 &&
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dmesg.c:269:6: note: uninitialized use occurs here
if (trace_name) {
^~~~~~~~~~
dmesg.c:263:3: note: remove the 'if' if its condition is always true
if (strcmp(basename, G_DIR_SEPARATOR_S) != 0 &&
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dmesg.c:263:7: error: variable 'trace_name' is used uninitialized whenever '&&' condition is false [-Werror,-Wsometimes-uninitialized]
if (strcmp(basename, G_DIR_SEPARATOR_S) != 0 &&
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dmesg.c:269:6: note: uninitialized use occurs here
if (trace_name) {
^~~~~~~~~~
dmesg.c:263:7: note: remove the '&&' if its condition is always true
if (strcmp(basename, G_DIR_SEPARATOR_S) != 0 &&
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dmesg.c:248:24: note: initialize the variable 'trace_name' to silence this warning
const char *trace_name;
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Francis Deslauriers [Tue, 18 Dec 2018 20:21:07 +0000 (15:21 -0500)]
Fix: setting the wrong status variable on query canceled
This fixes the following Clang warning:
query-executor.c:137:12: error: implicit conversion from enumeration type 'enum bt_query_executor_status' to different enumeration type 'enum bt_query_status' [-Werror,-Wenum-conversion]
status = BT_QUERY_EXECUTOR_STATUS_CANCELED;
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Francis Deslauriers [Tue, 18 Dec 2018 18:23:32 +0000 (13:23 -0500)]
Cleanup: add bt_ctf_value_type stringifying function
This fixes the following Clang warning:
trace.c:270:5: error: implicit conversion from enumeration type 'enum
bt_ctf_value_type' to different enumeration type 'enum bt_value_type'
[-Werror,-Wenum-conversion]
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Francis Deslauriers [Tue, 18 Dec 2018 17:49:57 +0000 (12:49 -0500)]
Cleanup: remove bt_clock_snapshot_set_value_inline function
The `bt_clock_snapshot_set_value_inline` function used to be an
augmented version of the `bt_clock_snapshot_set_raw_value` containing extra
pre-condition checks. Those checks were removed by a previous commit titled:
"CTF IR -> Trace IR"
so this extra function is not needed anymore.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Francis Deslauriers [Tue, 18 Dec 2018 18:09:48 +0000 (13:09 -0500)]
Cleanup: bt_clock_snapshot_set_raw_value is now a static inline
This fixes the following Clang warning:
In file included from clock-class.c:32:
../../include/babeltrace/trace-ir/clock-snapshot-internal.h:98:1: error: attribute declaration must precede definition [-Werror,-Wignored-attributes]
BT_HIDDEN
^
../../include/babeltrace/babeltrace-internal.h:77:34: note: expanded from macro 'BT_HIDDEN'
#define BT_HIDDEN __attribute__((visibility("hidden")))
^
../../include/babeltrace/trace-ir/clock-snapshot-internal.h:69:6: note: previous definition is here
void bt_clock_snapshot_set_raw_value(struct bt_clock_snapshot *clock_snapshot,
^
1 error generated.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Francis Deslauriers [Mon, 17 Dec 2018 22:44:30 +0000 (17:44 -0500)]
flt.utils.muxer: fix muxer_init prototypes
Fix mismatch of prototypes between declaration and definition of
function muxer_init.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Francis Deslauriers [Mon, 17 Dec 2018 16:53:14 +0000 (11:53 -0500)]
Add bt_self_message_iterator_status_string() function
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Philippe Proulx [Tue, 18 Dec 2018 22:16:33 +0000 (17:16 -0500)]
lib: do not allow port to be removed when message iterators are active
This patch makes it illegal to remove a port when at least one message
iterator using it is not finalized (or in the process of being
finalized).
This introduces the following advantages:
* From a downstream point of view, your upstream message iterator cannot
randomly get canceled, because a connection cannot end while any
message iterator is active.
Therefore the `BT_MESSAGE_ITERATOR_STATUS_CANCELED` status is removed.
This status was ambiguous and there was no clear indication of what to
do when you get it. Current plugins were handling it like
`BT_MESSAGE_ITERATOR_STATUS_END`.
* There's a precondition that you when you call
bt_self_component_port_input_message_iterator_next(), the iterator
must be active. In practice this is always the case because the only
way for it to be finalized if when you actively put its last
reference, and you should know it.
Therefore bt_self_component_port_input_message_iterator_next() does
not need to check the "finalized" status every time you call it in
case it needs to return the removed
`BT_MESSAGE_ITERATOR_STATUS_CANCELED` status.
To distinguish between "finalized" and "in the process of being
finalized", the (internal)
`BT_SELF_COMPONENT_PORT_INPUT_MESSAGE_ITERATOR_STATE_FINALIZING` is
introduced: when a message iterator is finalized, its state is set to
`BT_SELF_COMPONENT_PORT_INPUT_MESSAGE_ITERATOR_STATE_FINALIZING`, then
its finalization method is called, then its state is set to
`BT_SELF_COMPONENT_PORT_INPUT_MESSAGE_ITERATOR_STATE_FINALIZED`. You can
remove a component's port when all its message iterators have one of
those states.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Tue, 18 Dec 2018 14:54:49 +0000 (09:54 -0500)]
plugins/ctf/fs-src/fs.c: "msgier" -> "notifier"
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Tue, 18 Dec 2018 14:51:51 +0000 (09:51 -0500)]
lib: "msgied" -> "notified" (remaining of a previous mass rename)
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Tue, 18 Dec 2018 14:49:38 +0000 (09:49 -0500)]
CLI: use -x as short option for --connection instead of -C
This is easier to identify on a `run` command line than -c and -C used
together, with arguments that look a lot similar.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Wed, 12 Dec 2018 23:43:31 +0000 (18:43 -0500)]
Fix: graph API: add listeners to support filter-to-filter connection
Listeners existed to be notified when a source is connected to a filter
or to a sink, or when a filter is connected to a sink, but not when a
filter is connected to another filter.
Reported-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Tue, 11 Dec 2018 22:43:05 +0000 (17:43 -0500)]
lib: remove CTF concepts of packet and event headers
Packet and event headers are CTF concepts. In CTF 1.8, the fields in
those scopes are reserved for format encoding/decoding purposes, and
everything they mean has its equivalent property in trace IR objects.
I know no tracers producing CTF which put something else than the known
encoding fields in packet and event headers. Everything not related to
the trace format itself goes into context fields (except for a packet's
total and content sizes which are packet context fields), which are
still available as of this patch. This is so true that Mathieu Desnoyers
confirmed that CTF 2 should explicitly disallow anything else than
format-specific fields in header scopes. However, it might be ambiguous
in CTF v1.8.2, and someone somewhere could have put user fields in
there.
Therefore, for the moment, the `ctf` plugin does not copy the values of
packet and event header fields to trace IR fields. This could be done in
the future if we find that it's a limitation: for example, prefix header
fields with `ctf-header-` and put them into appropriate context fields
(packet context for packet header and event common context for event
header).
To make sure the user knows about non-CTF header fields being removed,
the `ctf` plugin prints a warning for each such field, for example:
12-12 10:53:25.904 21954 21954 W
PLUGIN-CTF-METADATA-META-WARN-MEANINGLESS-HEADER-FIELDS
warn_meaningless_field@ctf-meta-warn-meaningless-header-fields.c:32
User field found in packet header: ignoring: name="allo"
12-12 10:53:25.904 21954 21954 W
PLUGIN-CTF-METADATA-META-WARN-MEANINGLESS-HEADER-FIELDS
warn_meaningless_field@ctf-meta-warn-meaningless-header-fields.c:32
User field found in event header: ignoring: name="msg_id"
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Mon, 10 Dec 2018 21:19:32 +0000 (16:19 -0500)]
bt_field_class_*_create(): accept mandatory trace class
This patch makes all the field class creation functions accept a
mandatory trace class parameter. This parameter is not used for the
moment, but it could serve in the future to control allocation (for
example, object pooling), bookkeeping, and validation.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Mon, 10 Dec 2018 16:13:21 +0000 (11:13 -0500)]
bt_clock_class_create(): accept mandatory trace class
This patch makes bt_clock_class_create() accept a mandatory trace class
parameter. This parameter is not used for the moment, but it could serve
in the future to control allocation (for example, object pooling),
bookkeeping, and validation.
I'm adding a public bt_util_clock_cycles_to_ns_from_origin() function to
get the nanoseconds from an origin using custom offsets and frequency.
This is the equivalent of bt_clock_class_cycles_to_ns_from_origin(), but
you don't need a clock class object, just its properties.
The `ctf` plugin is updated so that its CTF IR API has a
`struct ctf_clock_class`. `bt_clock_class` was the only remaining trace
IR object that was used as is, but it's not possible anymore because a
CTF IR metadata tree can exist without a trace IR trace class, and you
need a trace IR trace class to create a trace IR clock class. The
bt_clock_class_cycles_to_ns_from_origin() calls are replaced with
bt_util_clock_cycles_to_ns_from_origin() calls, passing the raw CTF IR
clock class properties.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Mon, 10 Dec 2018 13:03:58 +0000 (08:03 -0500)]
bt_trace_class_create(): accept mandatory self component
This patch makes bt_trace_class_create() accept a mandatory self
component. The self component parameter is not used now, but it could be
in the future to control allocation (object pooling) and for
bookkeeping, as well as to have a system where a new trace class within
the graph can lead to notifying other components about it so they can
prepare associated data.
The `ctf` plugin is changed so that it does not require a trace class to
create packet indexes. This is required because the `trace-info` query
requires packet indexes to exist, but there's no self component in this
context to create a trace class.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Sat, 8 Dec 2018 21:29:36 +0000 (16:29 -0500)]
Component class API: use status
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Sat, 8 Dec 2018 21:09:46 +0000 (16:09 -0500)]
lib: add aliases for Babeltrace enumeration types
And uses aliases in CLI, plugins, and tests.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Sat, 8 Dec 2018 20:47:12 +0000 (15:47 -0500)]
Plugin development API: use self enumeration and plugin types
This is similar to a component class method accepting a self component
object.
The self plugin API is empty for the moment, but we might want to add
functions which do not apply to plugin or const plugin objects later
(for example, a function to set a self plugin's private data).
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Sat, 8 Dec 2018 20:38:21 +0000 (15:38 -0500)]
lib: remove unused public `enum bt_plugin_status`
Also:
* Make the plugin's user exit function return nothing. It's not like we
can cancel this anyway.
* Make the plugin's user init function return
`enum bt_plugin_init_status`, an enumeration reserved for this
function, in case `enum bt_plugin_status` becomes public in the
future.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Sat, 8 Dec 2018 20:26:46 +0000 (15:26 -0500)]
Trace API: use status
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Sat, 8 Dec 2018 20:23:57 +0000 (15:23 -0500)]
Stream API: use status
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Sat, 8 Dec 2018 20:23:48 +0000 (15:23 -0500)]
Trace class API: use status
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Sat, 8 Dec 2018 20:17:58 +0000 (15:17 -0500)]
Stream class API: use status
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Sat, 8 Dec 2018 20:13:56 +0000 (15:13 -0500)]
Packet API: use status
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Sat, 8 Dec 2018 20:11:23 +0000 (15:11 -0500)]
Field API: use status
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Sat, 8 Dec 2018 20:05:08 +0000 (15:05 -0500)]
Field class API: use status
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Sat, 8 Dec 2018 19:58:30 +0000 (14:58 -0500)]
Event API: use status
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Sat, 8 Dec 2018 19:54:23 +0000 (14:54 -0500)]
Event class API: use status
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Sat, 8 Dec 2018 19:47:56 +0000 (14:47 -0500)]
Clock snapshot API: use status
`enum bt_clock_snapshot_status` is renamed to `enum
bt_clock_snapshot_state` (known or unknown), while `enum
bt_clock_snapshot_status` is the API status enumeration like with other
APIs.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Sat, 8 Dec 2018 19:23:13 +0000 (14:23 -0500)]
Clock class API: use status
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Sat, 8 Dec 2018 19:00:41 +0000 (14:00 -0500)]
Remove unused lib/graph/message/discarded-{events,packets}.c
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Sat, 8 Dec 2018 18:46:17 +0000 (13:46 -0500)]
lib: rename "clock value" -> "clock snapshot"
This is more consistent with the current counter snapshots in the packet
API.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Sat, 8 Dec 2018 18:07:25 +0000 (13:07 -0500)]
lib: rename "notification" -> "message"
The term "notification" is usually used, in APIs, for asynchronous
alerts of some sort. You get notified for something that you were not
actively waiting for, like an interrupt.
From Merriam-Webster, a _message_ is:
> a communication in writing, in speech, or by signals
and a _communication_ is:
> information communicated : information transmitted or conveyed
Therefore, "message" seems more adapted than "notification" for
Babeltrace's API, where you actively iterate messages which are
communications from an upstream component to a downstream component.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Sat, 8 Dec 2018 17:44:10 +0000 (12:44 -0500)]
lib: rename bt_plugin_create_all_*() -> bt_plugin_find_all_*()
Those functions return a const plugin set anyway, so we're not really
creating private objects as other *_create() functions do.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Sat, 8 Dec 2018 17:30:25 +0000 (12:30 -0500)]
lib: add aliases for Babeltrace structure types
And uses aliases in CLI, plugins, and tests.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Fri, 7 Dec 2018 22:33:41 +0000 (17:33 -0500)]
lib: make public reference count functions have strict types
Instead of having generic bt_object_get_ref() and bt_object_put_ref()
accepting `const void *`, have one pair of such functions for each
shared object API.
This can help catch reference count bugs (not putting or getting the
correct object type) and makes it illegal at build time to get or put a
unique object's reference.
Each shared object API also has its own BT_X_PUT_REF_AND_RESET() and
BT_X_MOVE_REF() macros.
bt_object_get_ref() and bt_object_put_ref() are now internal and only
used by the library's implementation.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Fri, 7 Dec 2018 21:44:13 +0000 (16:44 -0500)]
lib: update copyrights
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Fri, 7 Dec 2018 21:23:29 +0000 (16:23 -0500)]
lib: rename plural file names to singular
For example, the object is `struct bt_value` so name the header file
`value.h`.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Fri, 7 Dec 2018 20:46:36 +0000 (15:46 -0500)]
lib: rename "begin" to "beginning" when used as a noun
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Fri, 7 Dec 2018 20:33:02 +0000 (15:33 -0500)]
bt_value_copy(): put output parameter as last parameter
To remain consistent, make the first parameter the main object on which
we're working.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Fri, 7 Dec 2018 20:30:01 +0000 (15:30 -0500)]
bt_value_map_extend(): put output parameter as last parameter
To remain consistent, make the first parameter the main object on which
we're working.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Fri, 7 Dec 2018 20:23:05 +0000 (15:23 -0500)]
Fix typo: "field classe" -> "field class"
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Fri, 7 Dec 2018 20:02:41 +0000 (15:02 -0500)]
lib: split trace API into trace class and trace APIs
This patch adds the _trace class_ object and its API, moving some trace
API functions to this one instead.
The trace object was the only one holding both metadata and data objects
(stream classes and streams, for example). To be more consistent, a
trace class now deals with metadata only (no streams, no static state)
and a trace with data only. A trace is an instance (data streams) of a
trace class: you can have many traces described by the same trace class.
You create a trace class with no parameters, while you create a trace
with an existing trace class.
Like for the trace object, the trace class API has both const and
non-const APIs.
Both a trace and a trace class can have a name (optional), just like
both a stream and a stream class can have a name, and so on. With this
patch, I chose to set the name of the trace object in both src.ctf.fs
and src.text.dmesg, and to display the trace object's name in
sink.text.pretty.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Tue, 4 Dec 2018 22:07:29 +0000 (17:07 -0500)]
lib: make graph API const-correct
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Tue, 4 Dec 2018 22:03:22 +0000 (17:03 -0500)]
lib: make plugin API const-correct
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Tue, 4 Dec 2018 21:32:13 +0000 (16:32 -0500)]
Fix: notif-iter.c: handle single/implicit SC/EC correctly
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Tue, 4 Dec 2018 21:31:45 +0000 (16:31 -0500)]
Fix: ctf-meta-update-meanings.c: only update if root struct FC exists
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Tue, 4 Dec 2018 20:29:10 +0000 (15:29 -0500)]
lib: make trace IR API const-correct
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Mon, 3 Dec 2018 23:39:58 +0000 (18:39 -0500)]
lib: make values API const-correct
This patch sets out the ground for subsequent const-correctness patches.
The rules are:
* Convert private API to non-const API, without any `private` prefix,
including in the file name. A non-const API function accept a
non-const object.
Put common enumerations in this header.
* Convert public API to const API:
* Use `-const.h` suffix in file name.
* Use `_const` suffix to borrowing functions and callback type
definitions.
In this particular patch, the `bt_value_null` singleton object is
non-const because you can use it with bt_value_array_append_element()
and bt_value_map_insert_entry().
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Mon, 3 Dec 2018 21:43:05 +0000 (16:43 -0500)]
lib: bt_object_{get,put}_ref(): accept a `const` parameter
This is the first step to make the whole API const-correct.
bt_object_get_ref() and bt_object_put_ref() are not considered to
logically modify the object: they change the reference count, but the
object's readable properties remain unchanged. Considering this, it is
simpler to have a single version of each of them accepting a const
object so as to be able to get and put const objects (eventually).
bt_object_put_ref() can have the effect of destroying/freeing the
object, just like Linux's kfree() does while accepting a `const void *`
parameter.
It is safe to cast away `const` in this library because the user only
passes opaque handles to functions (`struct bt_X *` types) pointing to
non-const objects defined by the library itself in writable memory
(usually through g_new0()).
In C++11, the equivalent of having a `const struct bt_X *` object on
which you can increment and decrement the reference count would be
having an `std::shared_ptr<const bt_X>` object: the wrapper is mutable,
but the contained object is const.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Mon, 3 Dec 2018 21:08:48 +0000 (16:08 -0500)]
CTF writer: use own `bt_ctf_object` and `bt_ctf_value` internal APIs
Removing CTF writer's implementation's dependency on `bt_object` and
`bt_value` makes it even more independent so as to be free to change the
`bt_object` and `bt_value` APIs without having to update the CTF writer
part.
Both APIs are not public as of this patch, so I'm hiding the public CTF
writer functions to get a trace's environment field (and their tests),
which is a `bt_ctf_value` object. This is not breaking backward
compatibility with Babeltrace 1.5.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Fri, 30 Nov 2018 22:22:43 +0000 (17:22 -0500)]
lib: move plugin set API declarations to `babeltrace/plugin/plugin-set.h`
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Fri, 30 Nov 2018 22:15:03 +0000 (17:15 -0500)]
lib: have separate `BT_QUERY_EXECUTOR_STATUS` and `BT_QUERY_STATUS`
The former is for the query executor API, the latter is returned by an
actual user-defined query method. `BT_QUERY_STATUS` does not have
"canceled" and "unsupported" entries, so we can remove those checks from
bt_private_query_executor_query() after calling the user method.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Fri, 30 Nov 2018 22:00:02 +0000 (17:00 -0500)]
lib: remove BT_NOTIFICATION_TYPE_{UNKNOWN,NR}
`BT_NOTIFICATION_TYPE_UNKNOWN` is not needed because we never return it.
`BT_NOTIFICATION_TYPE_NR` is an implementation detail, so we use the
last value instead.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
This page took 0.049071 seconds and 4 git commands to generate.