From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: A new direction for vmchannel? Date: Sun, 25 Jan 2009 11:58:01 -0600 Message-ID: <497CA829.5050105@codemonkey.ws> References: <4979D80D.307@us.ibm.com> <20090124171928.GA30108@redhat.com> <497B5546.5060000@codemonkey.ws> <20090125141657.GA30222@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gleb Natapov , Dor Laor , Avi Kivity , "qemu-devel@nongnu.org" , Eric Van Hensbergen , kvm-devel , Chris Wright To: "Daniel P. Berrange" Return-path: Received: from yx-out-2324.google.com ([74.125.44.30]:23850 "EHLO yx-out-2324.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750762AbZAYR6S (ORCPT ); Sun, 25 Jan 2009 12:58:18 -0500 Received: by yx-out-2324.google.com with SMTP id 8so2456638yxm.1 for ; Sun, 25 Jan 2009 09:58:16 -0800 (PST) In-Reply-To: <20090125141657.GA30222@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Daniel P. Berrange wrote: > On Sat, Jan 24, 2009 at 11:52:06AM -0600, Anthony Liguori wrote: > >>> 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. > It would be pretty trivial to have a small guest daemon that runs and makes a file system stream available as a unix socket. For instance, you would have: /qemufs/org/libvirt/qemud/stream0 The daemon would create a unix socket, /qemufs/org/libvirt/qemud/stream0.sock, and would spawn a thread that constantly read from /qemufs/org/libvirt/qemud/stream0 providing the data in the stream0.sock's buffer. I think that's a pretty reasonable compromise if that interface is strongly required. Maybe even just a library to provide that level of functionality? So you could have a function that was essentially vmc_open_as_stream("/org/libvirt/qemud/stream0") and the library would spawn a thread and create a unix domain socketpair() and return the appropriate end. That eliminates the need to have a daemon running. Regards, Anthony Liguori Regards, Anthony Liguori > Daniel >