[PATCH] getty: Wait until all output written to stdout has beentransmitted

[Peter Korsgaard]

>>>>> "Jim" == Cathey, Jim <jcathey at ciena.com> writes:

Hi,

 Jim> Forgive my lack of paying attention, but then what is the point
 Jim> of the drain at all?  It'll drain in its own time.  The usual
 Jim> need for a drain is to prevent race conditions with a device
 Jim> close or mode change (like baud rate) that might chop off or
 Jim> mangle the pending output.  Or is there some other race here?

I don't know the original reason for the tcflush(), but presumably it's
because of setups with sw flowcontrol, where the other end has sent xoff
and then crashed or gotten disconnected or so on.

This thread started by Michal, who's trying to use a very slow
serial-over-jtag setup on microblaze, and had issues with characters
getting lost when getty started up (because of the tcflush), so we
wanted to add a tcdrain() instead.

 >> And yes, STDOUT_FILENO would be somewhat clearer (but wouldn't matter
 Jim> as
 >> we just did xdup2(0, 1)), but I kept it as STDIN to match the tcflush
 >> just below.

 Jim> But tcflush of stdin throws away pending _input_, does it not?
 Jim> The fact that the two devices are connected together doesn't
 Jim> affect the semantics of fiddling with input versus output streams.

That depends on the flags:

       TCIFLUSH
              flushes data received but not read.

       TCOFLUSH
              flushes data written but not transmitted.

       TCIOFLUSH
              flushes  both  data  received but not read, and data written but
              not transmitted.

Getty is using TCIOFLUSH, E.G. both.

 Jim> I find it confusing to apply output ops to input streams, but
 Jim> that just happen to work given the setup circumstances.  Makes
 Jim> things seem like they're trickier than they actually are, which
 Jim> is usually not a good thing.

Indeed. In this case I'm not sure I find:

tcflush(STDIN_FILENO, TCIFLUSH);
tcflush(STDOUT_FILENO, TCOFLUSH);

much clearer than the single tcflush() though.

-- 
Bye, Peter Korsgaard