Open walkiry opened 1 year ago
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 the cur_last_event_ts
and off_pc_timestamp_end
fields of struct barectf_A_ctx
(both don't exist in struct barectf_B_ctx
).barectf_A_close_packet()
also needs the off_pc_events_discarded
field of struct barectf_A_ctx
to 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!
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.