Clarify buffer ownership for ByteStreamDriverModel

[celskeggs]

Related Issue(s)	n/a
Has Unit Tests (y/n)	n/a
Documentation Included (y/n)	yes

---

Change Description

TcpClientComponentImpl::send_handler and TcpServerComponentImpl::send_handler deallocate the provided Fw::Buffer if (and only if) they return SEND_OK or SEND_ERROR. If they return SEND_RETRY, they do not deallocate the buffer.

Rationale

To make sure that users of the ByteStreamDriverInterface can implement the correct buffer handling logic, it's important to define what happens with ownership of the buffer.

Testing/Review Recommendations

N/A

Future Work

UdpComponentImpl::send_handler does not implement the interface in the same way: notably, it also deallocates the buffer when it returns SEND_RETRY. I believe this is incorrect and has not been noticed because SEND_RETRY is unlikely (or maybe impossible) for UDP connections. Some revision to that code may be necessary.

[LeStarch]

@celskeggs thanks for this clarification! Also, you are right on the UDP issue and we should fix it for conformity with this pattern.

I took a look at the UART driver (also a byte stream) and it has one line we might review:

fprime/Drv/LinuxUartDriver/LinuxUartDriver.cpp

Line 334 in 00c5c8e

if (isConnected_deallocate_OutputPort(0)) {

That is, it only takes ownership in the case when the port is attached. I'd argue that it would be better to require that port to be attached. There are other patterns to prevent deallocation that would be clearer given the intended constraints of this pattern you documented here.