Use known context to close/open stream, question and possible change in v3.1 onward
Hi, I am considering using the library, however, I am spotting some design choices that I do not understand regarding the open/close packet.
As I understand the packets are closed by the function when the barectf engine is call the callbacks. I understand why you let the user call the function that actually closes the stream's packet.
However, I do not understand why would you use a stream's specific function ( e.g barectf_my_stream_close_packet) rather than a generic function to allow an easy re-usability (e.g close_stream_packet(ctx)). The context holds all the information necessary for this to be possible.
And even better. To allow the same trace to share the callbacks, why not create a barectf ctx and attach all the different streams to it? So we could gain even more re-usability.
Hi there!
A packet closing function is stream-type-specific because it handles stream-type-specific features.
For example, consider this configuration:
%YAML 1.2
--- !<tag:barectf.org,2020/3/config>
trace:
type:
native-byte-order: little-endian
$include:
- stdint.yaml
clock-types:
clk: {}
data-stream-types:
A:
$default-clock-type-name: clk
event-record-types:
evt:
payload-field-type:
class: structure
members:
- val: uint32
B:
$features:
packet:
discarded-event-records-counter-snapshot-field-type: false
event-record-types:
evt:
payload-field-type:
class: structure
members:
- val: uint32
In the generated barectf.c file, the packet closing functions are different, that is:
-
barectf_A_close_packet()gets a value from the user-defined clock value callback and needs thecur_last_event_tsandoff_pc_timestamp_endfields ofstruct barectf_A_ctx(both don't exist instruct barectf_B_ctx). -
barectf_A_close_packet()also needs theoff_pc_events_discardedfield ofstruct barectf_A_ctxto know where to write the discarded event record counter snapshot value within the packet context.
Therefore you need to call barectf_A_close_packet() when closing a packet of a data stream of type A and barectf_B_close_packet() when closing a packet of a data stream of type B.
For two data stream types having a default clock type and the exact same features, however, I get your point: barectf could generate a single pair of opening/closing functions for them. Maybe we could define a named class of data stream types in the configuration and link data stream types to this class. Something like this. The tool is just not there yet!