From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LR5nO-0001zl-9d for qemu-devel@nongnu.org; Sun, 25 Jan 2009 09:17:06 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LR5nM-0001zK-5P for qemu-devel@nongnu.org; Sun, 25 Jan 2009 09:17:04 -0500 Received: from [199.232.76.173] (port=54568 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LR5nL-0001zG-TS for qemu-devel@nongnu.org; Sun, 25 Jan 2009 09:17:03 -0500 Received: from mx1.redhat.com ([66.187.233.31]:52929) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LR5nL-0000ku-LD for qemu-devel@nongnu.org; Sun, 25 Jan 2009 09:17:03 -0500 Date: Sun, 25 Jan 2009 14:16:57 +0000 From: "Daniel P. Berrange" Message-ID: <20090125141657.GA30222@redhat.com> References: <4979D80D.307@us.ibm.com> <20090124171928.GA30108@redhat.com> <497B5546.5060000@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <497B5546.5060000@codemonkey.ws> Subject: [Qemu-devel] Re: A new direction for vmchannel? Reply-To: "Daniel P. Berrange" , qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Eric Van Hensbergen , Chris Wright , Gleb Natapov , kvm-devel , Dor Laor , "qemu-devel@nongnu.org" , Avi Kivity On Sat, Jan 24, 2009 at 11:52:06AM -0600, Anthony Liguori wrote: > Daniel P. Berrange wrote: > >On Fri, Jan 23, 2009 at 08:45:33AM -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?). Two aspects to main loop integration - for the filesystem as structured metadata use case, an efficient notifiction mechanism for discovering changes to files is key. For the stream based connection use case, obviously polling for incoming data / output write availabilty. > The way you would do this today, without special inotify support, is to > have a special file in the hierarchy called "change-notify". You can > write a list of deliminated files and whenever one of those files > becomes readable, the file itself will become readable (returning a > deliminated list of files that have changed since last read). > > This way, you get a file you can select on for a very large number of > files. That said, it would be nice to add proper inotify support to > v9fs too. There's probably two distinct user requirements here. For apps which need to implement something that'd work with vmchannel for both Linux and Windows guests, the special 'change-notify' file might be more convenient. For apps which want to work with native Linux APIs, then real inotify support would be desirable, since that's a standard interface across all filesystems in Linux. > > Regular > >files don't offer that kind of ability ordinarily, and not clear whether > >fifo's would be provided for in p9fs between host/guest ? > > > > I'm going to put together a patch this weekend and I'll include a > streaming example. Basically, you just ignore the file offset and > read/write to the file to your heart's content. Basically my use case would be that you have an existing application that supports UNIX domain sockets, and / or TCP sockets, and you wish to also have it run acros the host <-> guest channel. Although we're not using sockets here, being able to easily integrate into an app written around a sockets model is the high level goal. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|