qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 2/4] char: Add ability to provide a callback


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [PATCH v3 2/4] char: Add ability to provide a callback when write won't return -EAGAIN
Date: Tue, 20 Apr 2010 20:59:29 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]