Re: A new direction for vmchannel?

[Anthony Liguori <anthony@codemonkey.ws>]

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
>