Hallo Jim! > 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 activation.
> (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..." > Agreed. Me too. > 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. -- Harald _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox