ctf: make msg-iter not use bt_packet_context_field
The bt_packet_context_field API exists so that the CTF message iterator
could store packet context fields in contexts where it doesn't create
trace-ir objects. For example, in add_ds_file_to_ds_file_group, we use
a message iterator just to sniff the properties of the first packet of a
data stream file.
However, the CTF message iterator doesn't really use it anymore, it just
stores the relevant properties in fields of the ctf_msg_iter structure
and transfers them to the caller in ctf_msg_iter_get_packet_properties.
So the bt_packet_context_field API no longer has a reason to be. This
patch makes msg-iter stop using it, so it can be removed.
Currently, the packet_context_field is created when needed, which is
just before reading the packet context, in
read_packet_context_begin_state. A bt_packet is later created in
create_msg_packet_beginning, and the packet_context_field is moved into
the bt_packet.
If we want to get rid of the packet_context_field, it means we need to
create the bt_packet earlier (if not in dry_run mode), so it is
available in read_packet_context_begin_state, so that the packet context
fields are read directly into the bt_packet. And to create the
bt_packet, the bt_stream needs to be available. The bt_stream is
currently created just before sending the stream beginning message, in
ctf_msg_iter_get_next_message.
So this patch moves the creation of the bt_stream and bt_packet as early
as possible, just after we have read the packet header, in
after_packet_header_state. In read_packet_context_begin_state, we can
then find the packet already created in msg_iter->packet.
This change made it necessary to set the dry run flag on the CTF message
iterator in add_ds_file_to_ds_file_group (which should have probably
already been there anyway). This iterator is used to read the packet
context, which, previously, didn't trigger the creation of the bt_stream
and bt_packet. But now that we create those earlier, it is necessary
to set the flag to avoid them being created.
It was also needed to change the check in after_packet_context_state to
know whether we are at the first packet, and therefore need to emit a
stream beginning message, or if we are at a subsequent packet, and
therefore need to skip that step. We would previously check whether the
msg_it->stream field was set, but this is now always true given that we
set the stream earlier. The only way that I found to fix that is to add
the boolean flag emit_stream_beginning_message in the message iterator.
Change-Id: Ib907480727d00d51aabd89986375d533ad385c96
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2393
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
This page took 0.029154 seconds and 4 git commands to generate.