From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LQoDI-0004aO-Pm for qemu-devel@nongnu.org; Sat, 24 Jan 2009 14:30:40 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LQoDG-0004aB-D0 for qemu-devel@nongnu.org; Sat, 24 Jan 2009 14:30:39 -0500 Received: from [199.232.76.173] (port=45340 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LQoDG-0004a8-7U for qemu-devel@nongnu.org; Sat, 24 Jan 2009 14:30:38 -0500 Received: from yw-out-1718.google.com ([74.125.46.152]:37827) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LQoDF-0001E8-T0 for qemu-devel@nongnu.org; Sat, 24 Jan 2009 14:30:38 -0500 Received: by yw-out-1718.google.com with SMTP id 6so2189223ywa.82 for ; Sat, 24 Jan 2009 11:30:37 -0800 (PST) Message-ID: <497B6C4F.1040803@codemonkey.ws> Date: Sat, 24 Jan 2009 13:30:23 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4979D80D.307@us.ibm.com> <20090124171928.GA30108@redhat.com> <497B5546.5060000@codemonkey.ws> <20090124183912.GA7900@redhat.com> In-Reply-To: <20090124183912.GA7900@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: A new direction for vmchannel? Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Eric Van Hensbergen , Chris Wright , kvm-devel , Dor Laor , "qemu-devel@nongnu.org" , Avi Kivity Gleb Natapov wrote: > On Sat, Jan 24, 2009 at 11:52:06AM -0600, Anthony Liguori wrote: > >>> For use cases where you are exposing metadata from the host to the guest >>> this would be a very convenient approach indeed. As asked elsewhere in this >>> thread, my main thought would be about how well it suits a application that >>> wants a generic stream based connection between host & guest ? >>> Efficient integration into a poll(2) based event loop would be key to >>> that. >>> >> You mean for a very large number of files (determining which property >> has changed?). >> >> > I think what Daniel means is that for file to have stream semantic it is > not enough to ignore offset on read/write, but poll also should behave > similar to how it behaves with char device fd. With regular files poll > will always report that fd is ready for I/O. > Thinking more about this, the difficulty is that poll() only has useful semantics when you're dealing with a buffered stream of some sort. That is, poll() is only really capable of asking whether there is data pending in your read buffer. With 9P, you have to explicitly send a read request. You can implement buffered IO by simply sending constant read requests such that there is always one read request pending. I don't think it's useful to do this in the kernel. Unfortunately, there's no way to do async IO in userspace that doesn't suck so that would make this pretty difficult. We could use a thread pool, but that's somewhat soul crushing and doesn't scale well. I think that puts a requirement on v9fs to support linux-aio. Regards, Anthony Liguori > -- > Gleb. >