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: Daniel P. Berrange
Subject: [Qemu-devel] Re: A new direction for vmchannel?
Date: Sun, 25 Jan 2009 14:16:57 +0000
User-agent: Mutt/1.4.1i

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




reply via email to

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