On Wed, 2014-04-09 at 22:57 +0800, Xiao Jin wrote:
Thanks all for the review. We meet with the problems when developing
product. I would like to explain my understanding.
On 04/08/2014 11:05 AM, Xiao Jin wrote:
We find two problems on acm tty write delayed mechanism.
(1) When acm resume, the delayed wb will be started. But now
only one write can be saved during acm suspend. More acm write
may be abandoned.
The scenario usually happened when user space write series AT after acm
suspend. If acm accept the first AT, what's the reason for acm to refuse
the second AT? If write return 0, user space will try repeatedly until
resume. It looks simpler that acm accept all the data and sent out urb
when resume.
No. We cannot accept an arbitrary amount of data. It would let any
user OOM the system. There will have to be an arbitrary limit.
The simplest limit is 1 urb. And that is because we said that we
are ready to accept data.
(2) acm tty port ASYNCB_INITIALIZED flag will be cleared when
close. If acm resume callback run after ASYNCB_INITIALIZED flag
cleared, there will have no chance for delayed write to start.
That lead to acm_wb.use can't be cleared. If user space open
acm tty again and try to setd, tty will be blocked in
tty_wait_until_sent for ever.
We see tty write and close concurrently after acm suspend in this case.
It looks no method to avoid it from tty layer. acm_tty_write and
There is a delay user space can set.
acm_resume call after acm_port_shutdown. It looks any action in
acm_port_shutdown can't solve the problem. As acm has accepted the user
space data, we can only find a way to send out urb. I feel anyway to
discard the data looks like a lie to user space.
In my understanding acm should accept data as much as possible, and send
out urb as soon as possible. What do you think of?
There's certainly no problem with sending out the data. Yet
simply resuming the device in shutdown() should do the job.
Regards
Oliver