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

Rob Landley rob at landley.net
Tue Jan 25 02:17:37 UTC 2011


On 01/24/2011 03:42 PM, Denys Vlasenko wrote:
> On Monday 24 January 2011 21:03, Peter Korsgaard wrote:
>>>>>>> "Jim" == Cathey, Jim <jcathey at ciena.com> writes:
>> 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.
> 
> Unfortunately, Michal did not provide much of information:
> what is the speed of his serial link? how many characters
> are lost on average? How he starts getty? What architecture and CPU?
> Anything?
> 
> His last mail says that sleep(1) doesn't help, which I find
> hard to believe.

sleep(1) isn't sleep for 1 second, it's sleep for 1 milisecond.  2400bps
divided by 8 is 300 characters per second, so a milisecond delay does
nothing.  Even 9600 is 1200 chars per second, so an extra milisecond
wait is maybe "another character".  If he's on one of those embedded
plaforms where the serial chip has 1024 bytes of outbound buffer in it,
he'd need a full second wait at 9600 for it to drain.

More to the point, this is a heuristic that doesn't take the hardware
characteristics into account.  It's not "1/3 of a second is a good wait
based on human perception thresholds", this is "I have no idea how big
the hardware buffer is or what speed it's transmitting at, for all I
know somebody's hooked up to CB radio and transmitting at 110 bps over
three chained pringles can yagi hops."  There's nothing to base the
heuristic _on_.  Are there serial chips out there with 64k of buffer
(reasonable at a megabit per second), and if so will they ever get
driven at slower speeds than that for some reason (long cable serial
between floors in a building)?

Luckily, 90% of the time this stuff is done with cat5 these days.  (I've
seen cat5 stripped and used for serial connections, but ethernet handles
all this stuff for us and it's so cheap there's little reason _not_ to
use it, usually...)

Rob


More information about the busybox mailing list