serial console oddity
Don Lewis
truckman at FreeBSD.org
Sun Nov 9 11:15:38 PST 2003
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?
More information about the freebsd-current
mailing list