Re: [Qemu-devel] [PATCH 2/3] Always use nonblocking mode for qemu_chr_open_fd.

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 2447 bytes --]

(very old thread)

On Mon, 2008-07-28 at 14:20 +0200, Gerd Hoffmann wrote:
> Jamie Lokier wrote:
> > Is the problem that you want qemu to block when they do that?
> I want ptys behave as close as possible to tcp/unix sockets:
> 
>  * when nobody is connected, then don't send data.  Because we will
>    block forever once the kernel buffer is full, which is bad.
>  * when someone is connected, we want him get all data.  If the reader
>    is too slow to keep up, that means we will block now and then, yes.
>    Sockets do that too.

Hm? Sockets operate in O_NONBLOCK mode, don't they? 

If the other end stops consuming data and the kernel buffers fill up,
the serial driver ignores the resulting -EAGAIN and drops the byte.

And although it's "lossy", it's sane behaviour. It's exactly what you
get on a real RS232 serial line too; if the other end doesn't keep up
with reading the data out of its end, *it* is going to miss bytes.
That's always been the case, and I don't think we need to worry about
it.

We *certainly* shouldn't be blocking the whole guest CPU in the outb
instruction, waiting for ever for the other end to consume data. Which
is what we seem to do at the moment for PTYs.

> Additionally we can also try to drive the ptys / sockets / whatever
> filehandles in non-blocking mode and try propagating the state back to
> the guest so it stops writing.  That is a different issue, although
> related.  IIRC the xen guys have some bits for that ...

We *could*, I suppose, although as noted I'm not sure it's necessary. A
relatively easy answer might be for the serial driver to spot the
-EAGAIN and keep the byte in the transmit FIFO/register, and refrain
from reasserting THRE/TEMT until it's actually managed to send the
byte.

If we really wanted to support fully lossless serial communication, a
better option might be to implement the hardware flow control lines,
and assert CTS only when the (pty/socket/etc.) file descriptor is
writable. Then *if* the guest chooses to use hardware flow control,
that ought to work.

But I still don't think it's necessary. Can't we just make the PTY file
descriptor non-blocking, and then perhaps the monitoring logic added in
commit 279e694bc ("Attempt to detect unconnected ptys (Gerd Hoffman)")
can get simpler because it only has to poll an active device for
connectivity in the case where the write() fails.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4938 bytes --]