Re: [Qemu-devel] [PATCH v8 16/54] Return path: Open a return path on QEMUFile for sockets

[Dr. David Alan Gilbert]

* Daniel P. Berrange (address@hidden) wrote:
> On Tue, Sep 29, 2015 at 09:37:40AM +0100, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert" <address@hidden>
> > 
> > Postcopy needs a method to send messages from the destination back to
> > the source, this is the 'return path'.
> > 
> > Wire it up for 'socket' QEMUFile's.
> 
> I find this to be a pretty wierd approach to the problem. THe underlying
> transport is bi-directional, so I would expect to have a single QEMUFile
> object that allowed bi-directional I/O on it, rather than creating a
> second QEMUFile for the back channel, which was forbidden from closing
> the shared FD.
> 
> I can understand why you've done this though - since we only have a
> single buffer embedded in QEMUFile.  I wonder though if we'd be better
> off changing QEMUFile to have a 'inbuf' and 'outbuf' intead of just
> 'buf' and likewise iniov & outiov. Then we can allow bi-directional
> I/O on the single QEMUFile object which is a more natural fit.

The 'c' FILE* is one directional, and I just took it that the QEMUFile* is
like that; i.e. a buffered layer on top of an underlying one directional
transport. stdin,stdout are two separate FILE*'s.

Your iniov, outiov would be basically the same, so you'd end up duplicating
code for the in and out parts; where as what you really have is two of the same
thing wired up in opposite directions.

Having said that, for things like RDMA, they have to do special stuff for
each direction and the QEMUFile is really a shim on top of that.

Dave

> 
> Regards,
> Daniel
> -- 
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK