qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Eric Van Hensbergen <ericvanhensbergen@us.ibm.com>,
	Chris Wright <chrisw@redhat.com>, Gleb Natapov <gleb@redhat.com>,
	kvm-devel <kvm@vger.kernel.org>, Dor Laor <dlaor@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Avi Kivity <avi@redhat.com>
Subject: [Qemu-devel] Re: A new direction for vmchannel?
Date: Sun, 25 Jan 2009 14:16:57 +0000	[thread overview]
Message-ID: <20090125141657.GA30222@redhat.com> (raw)
In-Reply-To: <497B5546.5060000@codemonkey.ws>

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 :|

  parent reply	other threads:[~2009-01-25 14:17 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-23 14:45 [Qemu-devel] A new direction for vmchannel? Anthony Liguori
2009-01-23 17:12 ` [Qemu-devel] " Chris Wright
2009-01-23 17:37   ` Anthony Liguori
2009-01-23 20:43 ` Gleb Natapov
2009-01-23 20:58   ` Anthony Liguori
2009-01-24  0:02     ` Dor Laor
2009-01-24 10:22       ` Alexander Graf
2009-01-24 22:28         ` Dor Laor
2009-01-24 17:19 ` Daniel P. Berrange
2009-01-24 17:52   ` Anthony Liguori
2009-01-24 18:39     ` Gleb Natapov
2009-01-24 18:47       ` Anthony Liguori
2009-01-24 19:30       ` Anthony Liguori
2009-01-24 21:00         ` Jamie Lokier
2009-01-24 21:22           ` Anthony Liguori
2009-01-25 14:16     ` Daniel P. Berrange [this message]
2009-01-25 17:58       ` Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090125141657.GA30222@redhat.com \
    --to=berrange@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=avi@redhat.com \
    --cc=chrisw@redhat.com \
    --cc=dlaor@redhat.com \
    --cc=ericvanhensbergen@us.ibm.com \
    --cc=gleb@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).