Re: USB: Question about usb_write() API


Paul Sokolovsky
 

Hello Sundar,

On Tue, 30 Jan 2018 17:48:03 +0530
Sundar Subramaniyan <sundar.subramaniyan@gmail.com> wrote:

[]


My question now is, what is the ideal place to take care of
truncation and chunk handling as per the USB device stack design?
Why the driver needs to handle the multi-part write and
synchronization?

I understand that there are not going to be multiple USBD controllers
on a given chip and taking care of this in the
driver won't cost much from memory/CPU cycles point of view but from
USB DC driver implementation perspective
this might save a lot of time if the stack can abstract them.

Please let me know your opinions.
I'd suggest to look at this as a generic problem, not specific to USB
subsystem (e.g., there's the same issue in networking subsystem, etc.),
and consider the known best practices dealing with it. For example,
POSIX, when dealing with streams-of-bytes, always mandates possibility
of short reads/short writes (what you called "write in parts"). That
means that not drivers, but higher levels should take care of repeating
"long" operations.

This approach allows to implement simpler drivers (== easier to
write, less bugs), and allows for more flexibility on the higher levels.
But yes, the drawback of this approach is that it requires higher levels
to deal with repeating operations (POSIX passes that responsibility
all the way up to the application level, so each and every application
needs to have repetition loops*).

* Of course, that can be abstracted to a library. Different libraries
actually, because as mentioned, that's a flexible approach allowing
to implement different data flows and handling policies.


Thanks,
Sundar


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

Join devel@lists.zephyrproject.org to automatically receive all group messages.