Re: serial console oddity

On  9 Nov, Bruce Evans wrote:

> For a non-half-baked fix, do somethng like:
> - never block in ttymsg(), but always wait for output to drain using
>   tcdrain() in a single child process.  It's probably acceptable for
>   this to not report errors to ttymsg()'s caller.
> - limit children better.  I think we now fork children iff writev()
>   returns EWOULDBLOCK and this happens mainly when the tty buffers
>   fill up due to clocal being off and the external console not
>   listening.  Handling this right seems to require handing off the
>   messages to a single child process that can buffer the messages
>   in userland and can block writing and draining them.  Blocked write()s
>   and tcdrain()s are easy enough to handle in a specialized process by
>   sending signals to abort them.

Another way of handling EWOULDBLOCK would be to add the descriptor to
syslogd's select loop instead of forking a child process.  There is
still the issue of how to handle blocking trdrain()s or close()s,
perhaps a thread.  Syslogd should not attempt to re-open the device if a
tcdrain() or close() was in progress.

BTW, it sounds like the pending output should not be discarded by the
close(), the termios(4) man page says:

   Closing a Terminal Device File
     The last process to close a terminal device file causes any output to be
     sent to the device and any input to be discarded.

If output is discarded in the O_NONBLOCK case, it seems to be
undocumented.  Should close() return ENOSPC in this case?