|
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
[Prev in Thread] | Current Thread | [Next in Thread] |