Hello,
I've been developing a uart_driver for some custom hardware, and I've
noticed this behavior:
If a software writing a large amount of data is canceled (ctrl-c), then
some of its previous data is still present in the xmit buffer the next
time the device is opened by a second program, and thus transmission
begins again, regardless of the action of the second program.
To be more clear, this is the concrete scenario:
running "seq 1 100000000 > /dev/myttydevice" in order to generate some
data. Then hitting ctrl-c to abort it.
Then running "stty -F /dev/myttydevice -a" to check the settings.
When stty is started, my driver starts sending some more of the content
of the previous seq command, and, as this time stty is not canceled, the
uart_driver is waiting for the transmission to be finished before
closing, which takes several seconds as there can still be lots of data
to send.
Thus starting stty in order to check the configuration, resulting in
transmitting lots of previous data and a long time before the command
itself finishes seemed strange to me.
After looking into the code, I've come to the conclusion that the xmit
buffer is cleaned when the flush_buffer callback (uart_flush_buffer())
is called from the tty layer.
Which is done from tty_driver_flush_buffer(), which is done from
tty_port_close_start().
However tty_port_close_start() only calls it if the flag
tty->flow_stopped has been set, which is only set via some ioctl .
Thus the flush callback is not called in my case, and the xmit buffer is
not empty the next time the device is opened.
I've been using the kernel 4.14.222. I can't test easily with a more
recent kernel, as the main kernel would require a non trivial amount of
patches to be ported to the newer version. However looking at the diff
between this 4.14 version and the last lts version (5.10.60), I haven't
seen any changes relevant to that behavior.
As a workaround, I've been calling manually
uart_circ_clear(&port->state->xmit); in my startup callback.
So, is the described behavior expected ?
Did I forget to do something in my uart_driver that could explain this ?
Or something else that I missed ?
Best Regards,
Patrick Havelange
