libsel4camkes/virtqueue: use const qualifier#137
Conversation
|
It seems the test failure happens due to a race condition, where the output from different thread overlaps. Instead of |
| * @return 0 on success, -1 on fail | ||
| */ | ||
| int camkes_virtqueue_driver_send_buffer(virtqueue_driver_t *vq, void *buffer, size_t size); | ||
| int camkes_virtqueue_driver_send_buffer(virtqueue_driver_t *vq, const void *buffer, size_t size); |
There was a problem hiding this comment.
I think this function is also used for enqueuing buffers in the virtqueue to receive data on?
In this case send means that the buffer is being sent to the other end of the queue (the device side). If the queue is used for transmitting data then the data in the buffer would be read by the other end, but if the queue is being used for receiving data then the other side would modify the contents before sending it back.
There was a problem hiding this comment.
Fair point. Would it make sense to separate the APIs then for the different use cases to support proper semantics?
There was a problem hiding this comment.
What if the semantics are just enqueuing into available hands a mutable reference over, and receiving from the other queue takes it back. Whether the buffers are written to by the other side is a higher level concern depending on the protocol using the buffers.
axel-h
force-pushed
the
patch-axel-16
branch
2 times, most recently
from
1d38a2e to
1785419
Compare
axel-h
force-pushed
the
patch-axel-16
branch
from
1785419 to
d86d6f2
Compare
Ensure const correctness is kept. Sending a buffer implies that the buffer is not modified. Signed-off-by: Axel Heider <[email protected]>
2 participants
Ensure const correctness is kept. Sending a buffer implies that the buffer is not modified.
Without this change, there is always a compiler warning if a buffer with a
constqualifier is passed to these APIs. Casting away the const qualifier contradicts the intention of usingconst.