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
