|
From: | Anthony Liguori |
Subject: | [Qemu-devel] Re: [PATCH v7 4/6] char: Add qemu_chr_write_nb() for nonblocking writes |
Date: | Wed, 05 May 2010 08:53:31 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0 |
On 05/05/2010 08:34 AM, Paul Brook wrote:
I really dislike the idea of adding another function for this. Can you explain why you need this functionality for virtio-console and why this functionality isn't needed for everything else?This functionality should (in principle) be used by all serial port implementations. Physical serial ports are sufficiently crufty and low-performance that noone actually uses them nowadays. I expect that the only significant real-world use is for serial consoles, which never send enough data to care that writes stall the whole machine.
We don't implement control flow in the character driver layer today. Different backends use different policies. Some drop data (like pty) while other block (like tcp).
This patch adds optional control flow in a pretty crufty way to *some* backends but not all. This just adds a bunch of complexity that will certainly introduce bugs.
If we're going to make the char drivers implement control flow, then I think we should do it universally--not as an optional feature. For devices that can't participate in control flow, we should decide where the policy should be implemented (front-end or back-end) and in either approach, it's easy enough to make dropping data or blocking a choice.
Regards, Anthony Liguori
With virtio-serial we've made serial ports a viable solution to a whole range of problems. It's likely that applications that may send nontrivial amounts of data, or clients will not be ready to process the data immediately. Paul
[Prev in Thread] | Current Thread | [Next in Thread] |