Re: [Qemu-devel] [PATCH v3 2/4] char: Add ability to provide a callback when write won't return -EAGAIN

[Gerd Hoffmann <kraxel@redhat.com>]

On 04/20/10 14:28, Paul Brook wrote:
>> I sent out this series as a "feeler" to see if the approach was
>> acceptable.
>>
>> Paul didn't reply to my reply addressing his concern, so I take that as
>> he's OK with the approach as well :-)
>
> I'd probably exposed this as an asyncronous write rather than nonblocking
> operation. However both have their issues and I guess for character devices
> your approach makes sense (c.f. block devices where we want concurrent
> transfers).

For chardevs async operation introduces ordering issues, I think 
supporting non-blocking writes is more useful here.

> It would be useful to have a debugging mode where the chardev layer
> deliberately returns spurious EAGAIN and short writes. Otherwise you've got a
> lot of very poorly tested device fallback code. I have low confidence in
> getting this right first time :-)

It might be a good idea to have a different interface for it, i.e. 
qemu_chr_write() keeps current behavior and we'll add a new 
qemu_chr_write_nonblocking() for users which want (and can handle) the 
non-blocking behavior with short writes and -EAGAIN return values.

We should also clearly define what qemu_chr_write_nonblocking() should 
do in case the underlying chardev backend doesn't support nonblocking 
operation.  Option one is to fail and expect the caller handle the 
situation.  Option two is fallback to blocking mode.  I'd tend to pick 
option two, fallback to blocking mode is what the caller most likely 
will do anyway.

cheers,
   Gerd