[PATCH] getty: Wait until all output written to stdout has beentransmitted
jacmet at sunsite.dk
Mon Jan 24 20:03:29 UTC 2011
>>>>> "Jim" == Cathey, Jim <jcathey at ciena.com> writes:
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
>> 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:
flushes data received but not read.
flushes data written but not transmitted.
flushes both data received but not read, and data written but
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:
much clearer than the single tcflush() though.
Bye, Peter Korsgaard
More information about the busybox