Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use known context to close/open stream, question and possible change in v3.1 onward #29

Open
walkiry opened this issue May 8, 2023 · 1 comment

Comments

@walkiry
Copy link

walkiry commented May 8, 2023

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.

@eepp
Copy link
Member

eepp commented May 8, 2023

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants