[Toybox] microcom.c discarding data due to TCSAFLUSH

[Yi-Yo Chiang]

Found this out today when comparing captured logs. Every time I connect to
a pty the first few hundreds of bytes seem to always be missing.
I then traced to this line
https://github.com/landley/toybox/blob/master/toys/net/microcom.c#L103 and
it's the tcsetattr(TCSAFLUSH) that is discarding buffered input data.
Something like this is happening:

1. (process 1) opens and write "xxxxyyyy" to the ptmx end. The data is not
immediately read by another process, so it's buffered somewhere. (in the
pty driver?)
2. (process 2 / microcom) opens and flushes (TCSAFLUSH) the pts end, and
then start polling data. Receives "yyyy". Part of the buffered input data
were flushed and discarded.

Man page says (https://man7.org/linux/man-pages/man3/termios.3.html):

       TCSANOW
              the change occurs immediately.

       TCSADRAIN
              the change occurs after all output written to fd has been
              transmitted.  This option should be used when changing
              parameters that affect output.

       TCSAFLUSH
              the change occurs after all output written to the object
              referred by fd has been transmitted, and all input that
              has been received but not read will be discarded before
              the change is made.

Is there any particular reason to use TCSAFLUSH here?
If not, can we change to TCSADRAIN or TCSANOW. I don't think there is good
reason to _discard received data_ just to set the terminal mode...? Is
there really a real world case that the device termios is so dirty that all
data, from before setting raw mode, must be discarded?

I also tried to modify the microcom code to skip tcsetattr() if the device
termios is already equal to the mode we are setting it.
`if (old_termios != new_termios) tcsetattr(new_termios, TCSAFLUSH)`
However this doesn't work because microcom always tries to set the device
baud. For example a pty device might be configured to use buad 38400, but
microcom would want it to be 115200, thus flushing it's data. but pty
doesn't really care about the baud most of the time AFAIK, so flushing data
in this case just seems disruptive to the user experience.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20240520/5e25d25f/attachment.htm>