-
Notifications
You must be signed in to change notification settings - Fork 90
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
libtock: add util/streaming_process_slice #492
Conversation
e9a2c17
to
c6ed0ed
Compare
c6ed0ed
to
3f29461
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes sense to me. Pretty reasonably clean interface, with an excellently documented implementation. A couple of questions for you.
a3e0c8e
to
aa58332
Compare
This adds userspace helpers implementing the "streaming process slice" contract as implemented in the Tock kernel in [1]. Instead of working with two separate buffers, these helpers present an interface similar to a regular read-write allow based on a single buffer. Internally, this buffer is then subdivided into an "application-owned" and "kernel-owned" part which are swapped atomically. The caller is responsible for keeping a `streaming_process_slice_state_t`, and is provided with ephemeral references to the kernel-written payloads on each swap operation. The full, original buffer can be reclaimed by deinitializing the `streaming_process_slice_state_t` struct. Currently, these helpers are quite minimal and do not expose the ability to set any optional flags (such as `halt`). They are tested to work against against the interface implemented in [1] (with the fix of [2] included) as part of the LwIP Ethernet tap-driver userspace app. [1]: tock/tock#4208 [2]: tock/tock#4343
Instead of internally splitting a single buffer to create two halves used in the streaming process slice abstraction, this changes it to accept two separate buffers for the kernel- and application-owned buffer respectively. This was discussed on the pull request introducing this abstraction: #492 (comment) Suggested-by: Branden Ghena <[email protected]>
aa58332
to
5c24a44
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of changes for you.
I do think this is cleaner, although again if no one else cares I'm fine going with your single-buffer implementation instead.
Instead of internally splitting a single buffer to create two halves used in the streaming process slice abstraction, this changes it to accept two separate buffers for the kernel- and application-owned buffer respectively. This was discussed on the pull request introducing this abstraction: #492 (comment) Suggested-by: Branden Ghena <[email protected]>
ddb74c6
to
1a64253
Compare
This adds userspace helpers implementing the "streaming process slice" contract as implemented in the Tock kernel in 1. Instead of working with two separate buffers, these helpers present an interface similar to a regular read-write allow based on a single buffer. Internally, this buffer is then subdivided into an "application-owned" and "kernel-owned" part which are swapped atomically. The caller is responsible for keeping a
streaming_process_slice_state_t
, and is provided with ephemeral references to the kernel-written payloads on each swap operation. The full, original buffer can be reclaimed by deinitializing thestreaming_process_slice_state_t
struct.Currently, these helpers are quite minimal and do not expose the ability to set any optional flags (such as
halt
). They are tested to work against against the interface implemented in 1 (with the fix of 2 included) as part of the LwIP Ethernet tap-driver userspace app.