[PATCH] getty: Wait until all output written to stdouthas beentransmitted
ralda at gmx.de
Tue Jan 25 00:41:55 UTC 2011
> It is entirely possible for the system to be configured with something
> that holds the port open.
It is not proper use of getty to run on a tty that is open by any other
process at this time! Anything else is mangling at the wrong place. So
there should always be a close/open flush. Flushing within getty is for
elimination of waste received due to tty/modem control/handshake signal
> (The kernel should be responsible for taking care of its own
> business; not getty's job at all.)
Ok, I'm going to catch the problem ... I heard rumors of a bug, mixing
kernel and console output on jtag consoles (resulting in losing parts of
messages) ... did quick search but couldn't find a reference for this at
the moment ... but there is a problem belonging to this topic (jtag or
very slow serial consoles), at least in some kernel versions ... may be
I'm able to forward this question to the guy who told me about that
problem. I know he dig into and found the reason, what is exactly
happening, but wasn't able to fix it.
>> "Thanks for informing us that it is important.
>> It would be awesome if we would also be informed
>> WHY it is important..."
> This was (is) to prevent burning up the CPU time if there is some kind
> of hardware configuration problem that results in a looping close/open
> kind of thing.
That is a different kind of delay. Old inits had a special delay on tty
lines. I think it was to give the user a chance to see the output of the
last program, before tty got cleared from next console startup and to
allow the hardware of modems to do a proper reset before re-activation
of DTR/DSR signals.
More information about the busybox