qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: A new direction for vmchannel?


From: Anthony Liguori
Subject: [Qemu-devel] Re: A new direction for vmchannel?
Date: Sun, 25 Jan 2009 11:58:01 -0600
User-agent: Thunderbird 2.0.0.19 (X11/20090105)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]