non-aio USB read function was stuck in a loop waiting for more data
because data length parameter is always set 64 for fastbootd commands.
It should be a normal case to get less data than expected
since lengths of these commands are usually less than 64.
Add logic to check this and one more parameter to distinguish
fastbootd from general adbd case.
Bug: 133189029
Test: try various fastbootd commands
Change-Id: I6690324840d78f3f1e04235040301520329976db
Merged-In: I6690324840d78f3f1e04235040301520329976db
Implement a Connection that implements a nonblocking interface to
functionfs, to replace the existing implementation that uses two
threads that loop and call read and write respectively. The existing
implementation is vulnerable to a race condition that can occur when a
connection is terminated, where one thread can notice failure and
complete reinitialization of the USB endpoints before the other thread
noticed anything went wrong, resulting in either the first packet
coming from the other end disappearing in to the void, or the other end
getting a packet of garbage.
As a side benefit, this improves performance on walleye from:
push 100MiB: 10 runs: median 49.48 MiB/s, mean 50.00 MiB/s, stddev: 2.77 MiB/s
pull 100MiB: 10 runs: median 75.82 MiB/s, mean 76.18 MiB/s, stddev: 6.60 MiB/s
to:
push 100MiB: 10 runs: median 73.90 MiB/s, mean 73.51 MiB/s, stddev: 5.26 MiB/s
pull 100MiB: 10 runs: median 105.90 MiB/s, mean 107.19 MiB/s, stddev: 6.10 MiB/s
Test: python test_device.py
Change-Id: I9b77c1057965edfef739ed9736e5d76613adf60a
chihhao.chen
Josh Gao