From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50890) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQxck-0002sU-HH for qemu-devel@nongnu.org; Wed, 03 Feb 2016 08:37:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQxcg-0002yT-89 for qemu-devel@nongnu.org; Wed, 03 Feb 2016 08:37:34 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41013) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQxcg-0002yJ-0E for qemu-devel@nongnu.org; Wed, 03 Feb 2016 08:37:30 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 7B99C8F4FB for ; Wed, 3 Feb 2016 13:37:29 +0000 (UTC) Date: Wed, 3 Feb 2016 13:37:25 +0000 From: "Daniel P. Berrange" Message-ID: <20160203133725.GM30222@redhat.com> References: <1452599056-27357-1-git-send-email-berrange@redhat.com> <1452599056-27357-8-git-send-email-berrange@redhat.com> <20160202170623.GA4498@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160202170623.GA4498@work-vm> Subject: Re: [Qemu-devel] [PATCH v1 07/22] migration: introduce a new QEMUFile impl based on QIOChannel Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: Amit Shah , qemu-devel@nongnu.org, Juan Quintela On Tue, Feb 02, 2016 at 05:06:24PM +0000, Dr. David Alan Gilbert wrote: > * Daniel P. Berrange (berrange@redhat.com) wrote: > > Introduce a new QEMUFile implementation that is based on > > the QIOChannel objects. This impl is different from existing > > impls in that there is no file descriptor that can be made > > available, as some channels may be based on higher level > > protocols such as TLS. > > > > Although the QIOChannel based implementation can trivially > > provide a bi-directional stream, initially we have separate > > functions for opening input & output directions to fit with > > the expectation of the current QEMUFile interface. > > > > Signed-off-by: Daniel P. Berrange > > --- > > include/migration/qemu-file.h | 4 + > > migration/Makefile.objs | 1 + > > migration/qemu-file-channel.c | 201 ++++++++++++++++++++++++++++++++++++++++++ > > 3 files changed, 206 insertions(+) > > create mode 100644 migration/qemu-file-channel.c > > +static ssize_t channel_writev_buffer(void *opaque, > > + struct iovec *iov, > > + int iovcnt, > > + int64_t pos) > > +{ > > + QIOChannel *ioc = QIO_CHANNEL(opaque); > > + ssize_t done = 0; > > + ssize_t want = iov_size(iov, iovcnt); > > + struct iovec oldiov = { NULL, 0 }; > > + > > + while (done < want) { > > + ssize_t len; > > + struct iovec *cur = iov; > > + int curcnt = iovcnt; > > + > > + channel_skip_iov(done, &cur, &curcnt, &oldiov); > > + > > + len = qio_channel_writev(ioc, cur, curcnt, NULL); > > + if (oldiov.iov_base) { > > + /* Restore original caller's info in @iov */ > > + cur[0].iov_base = oldiov.iov_base; > > + cur[0].iov_len = oldiov.iov_len; > > + oldiov.iov_base = NULL; > > + oldiov.iov_len = 0; > > + } > > + if (len == QIO_CHANNEL_ERR_BLOCK) { > > + qio_channel_wait(ioc, G_IO_OUT); > > + continue; > > + } > > + if (len < 0) { > > + /* XXX handle Error objects */ > > + return -EIO; > > It's best to return 'len' rather than lose what little > error information you had (similarly below). In this case 'len' is in fact just '-1', as all error info is in the Error ** parameter, but the QEMUFile API contract requires an errno value. So we don't have much choice but to return a fixed EIO - returning 'len' would also be a fixed errno - whichever errno corresponds to the value -1. I'd like to switch QEMUFile over to use Error **errp parameters for error reporting, so that we can make detailed error info available throughout the migration I/O code. That ought to wait until after this series is done though, to avoid complicating it yet more. > > > + } > > + > > + done += len; > > + } > > + return done; > > +} > > + > > + > > +static ssize_t channel_get_buffer(void *opaque, > > + uint8_t *buf, > > + int64_t pos, > > + size_t size) > > +{ > > + QIOChannel *ioc = QIO_CHANNEL(opaque); > > + ssize_t ret; > > + > > + reread: > > + ret = qio_channel_read(ioc, (char *)buf, size, NULL); > > + if (ret < 0) { > > + if (ret == QIO_CHANNEL_ERR_BLOCK) { > > + qio_channel_yield(ioc, G_IO_IN); > > + goto reread; > > + } else { > > + /* XXX handle Error * object */ > > + return -EIO; > > + } > > + } > > + return ret; > > > I'd prefer a loop to a goto; generally the only places we > use goto is an error exit. > > do { > ret = qio_channel_read(ioc, (char *)buf, size, NULL); > if (ret == QIO_CHANNEL_ERR_BLOCK) { > qio_channel_yield(ioc, G_IO_IN); > } > } while (ret == QIO_CHANNEL_ERR_BLOCK); > > return ret; > > and IMHO the loop is clearer. Ok, will change that. 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 :|