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

Harald Becker ralda at gmx.de
Mon Jan 24 21:38:57 UTC 2011


 Hi all!

I'm watching a bit that tcflush/tcdrain discussion. As I currently can't
look inside the source, there are some question cycling in my brain ...
may be, some one has some answers for me:

- first of all: is that flush/drain at the start of getty or at the end
or at which point of the tty startup? ... to clarify: I do know getty
functionally, as I have written an alternate getty for mgetty for a
bulletin board system sharing a fax and voice mail system at the same
modem line.

- if at end of getty: do we really need it? wouldn't it just be enough
to flush the input (which is what is required to ignore bad character
reception on tty startup or wrong baud rate before change). Flushing the
input doesn't hang due to handshake considerations and leaves the output
queue untouched. A drain isn't required this way.

- if at start of getty: why is it required? as the tty should have been
closed and reopened before, the queues should already be empty. So which
output get lost, exactly please. What is that flush/drain for ... except
that very old bug, that changing line setup fails on none empty buffers?
... if at getty startup, a short delay of a second or so, wouldn't be
that bad, as it is the tty process startup. That would even be a good
idea, as old init processes sometimes delayed spawning of new (getty)
processes for several seconds (resulting in tty close - delay - open)
... which isn't done by busybox init (as far as I noted some time ago)
... which could be the reason if output from previous processes get
lost. ... due to this I needed to replace getty with a shell script like
this to work around some serial tty speed problems:

#!/bin/busybox sh
sleep 2s
exec /bin/busybox getty "$@"

... this script approach could be done on lines which require it,
leaving other lines and local tty's at no delay at all. On the other
hand, that small delay on slow lines doesn't harm at all. Why doing
complicated alarm/signal stuff? ... Nice and truly the best approach,
but why doing complicated things?

Would be nice, if anybody can give me some clarifications for this. Thx
ahead.

--
Harald



More information about the busybox mailing list