On 05/05/2010 01:40 PM, Gerd Hoffmann wrote:
+ return s->chr_write_nb(s, buf, len);
+}
I really dislike the idea of adding another function for this.
Having a explicit function for non-blocking mode IMHO is much better.
It makes things more clear when reading the code.
Previous approach was to check for O_NONBLOCK (extra syscall) and
behave differently depending on whenever it is set or not (too much
hidden magic).
Can you
explain why you need this functionality for virtio-console and why this
functionality isn't needed for everything else?
virtio-console is just the first user. 16550 emulation can use that
too. With the blocking interface you'll stall the guest (sitting in
the blocking write syscall) in case the outgoing pipe is full. With
the non-blocking interface you can simply delay the "you can send more
data" signal (update status register + raise IRQ) until you can
actually accept more data. Meanwhile the guest can continue to run
and do something else. Basically it allows to implement sane flow
control.
The use of char drivers is dominated by a small number of use cases
which include serial ports, the monitor, and QMP.
In all of those cases, the devices can and should participate in control
flow. IMHO, we should make control flow part of the standard interface
and fix all users appropriately.
I've seen blocking result in frozen guests many times in real
deployments. It's never the right thing to do as far as I can tell.
Regards,
Anthony Liguori
cheers,
Gerd
