On Wed, Jan 31, 2018 at 08:09:12AM +0530, Sundar Subramaniyan wrote:
On Tue, Jan 30, 2018 at 9:55 PM, Paul Sokolovsky
A good clarification thus would be:
1. bytes_ret is always not-NULL.
2. There can always be short writes, number of bytes written is
returned in *bytes_ret, caller must retry with remaining data as
Note that this doesn't call for updates to existing drivers - they can
keep accepting bytes_ret as NULL, and loop/block inside. But clients
of this API definitely need to be updated, because otherwise they
simply won't work with some drivers.
I think the same too. For now, new drivers should handle both the methods
to be coherent with the API definition. If ret_bytes is NULL, then it
a blocked write taking care of fragmentation of the packet internally
the driver. Otherwise if it is != NULL, it can let the upper layer do the
and shall *not* block-wait for the completion of the current write on the
since we have write callback for notification purpose.
I think we do not have now this requirement not to block-wait. When
working with sending fragmented packets you would prefer to block until all
fragments are sent.