From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33903) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axuaT-0000bp-Br for qemu-devel@nongnu.org; Wed, 04 May 2016 07:03:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1axuaA-0003Nn-Iu for qemu-devel@nongnu.org; Wed, 04 May 2016 07:03:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41072) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axuaA-0003Jp-C0 for qemu-devel@nongnu.org; Wed, 04 May 2016 07:03:06 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3ADAA64449 for ; Wed, 4 May 2016 11:02:55 +0000 (UTC) From: Juan Quintela In-Reply-To: <1461751518-12128-10-git-send-email-berrange@redhat.com> (Daniel P. Berrange's message of "Wed, 27 Apr 2016 11:04:59 +0100") References: <1461751518-12128-1-git-send-email-berrange@redhat.com> <1461751518-12128-10-git-send-email-berrange@redhat.com> Reply-To: quintela@redhat.com Date: Wed, 04 May 2016 13:02:52 +0200 Message-ID: <87vb2uf5lv.fsf@emacs.mitica> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH v6 for-2.7 09/28] migration: add helpers for creating QEMUFile from a QIOChannel List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org, "Dr. David Alan Gilbert" , Amit Shah "Daniel P. Berrange" wrote: > Currently creating a QEMUFile instance from a QIOChannel is > quite simple only requiring a single call to > qemu_fopen_channel_input or qemu_fopen_channel_output > depending on the end of migration connection. > > When QEMU gains TLS support, however, there will need to be > a TLS negotiation done inbetween creation of the QIOChannel > and creation of the final QEMUFile. Introduce some helper > methods that will encapsulate this logic, isolating the > migration protocol drivers from knowledge about TLS. > > Reviewed-by: Dr. David Alan Gilbert > Signed-off-by: Daniel P. Berrange > --- > include/migration/migration.h | 6 ++++++ > migration/migration.c | 21 +++++++++++++++++++++ > 2 files changed, 27 insertions(+) > > diff --git a/include/migration/migration.h b/include/migration/migration.h > index ac2c12c..e335380 100644 > --- a/include/migration/migration.h > +++ b/include/migration/migration.h > @@ -179,6 +179,12 @@ void process_incoming_migration(QEMUFile *f); > > void qemu_start_incoming_migration(const char *uri, Error **errp); > > +void migration_set_incoming_channel(MigrationState *s, > + QIOChannel *ioc); > + > +void migration_set_outgoing_channel(MigrationState *s, > + QIOChannel *ioc); > + > uint64_t migrate_max_downtime(void); > > void exec_start_incoming_migration(const char *host_port, Error **errp); > diff --git a/migration/migration.c b/migration/migration.c > index 4732915..794df84 100644 > --- a/migration/migration.c > +++ b/migration/migration.c > @@ -428,6 +428,27 @@ void process_incoming_migration(QEMUFile *f) > qemu_coroutine_enter(co, f); > } > > + > +void migration_set_incoming_channel(MigrationState *s, > + QIOChannel *ioc) > +{ > + QEMUFile *f = qemu_fopen_channel_input(ioc); > + > + process_incoming_migration(f); > +} > + > + > +void migration_set_outgoing_channel(MigrationState *s, > + QIOChannel *ioc) > +{ > + QEMUFile *f = qemu_fopen_channel_output(ioc); > + > + s->to_dst_file = f; > + > + migrate_fd_connect(s); > +} > + > + > /* > * Send a message on the return channel back to the source > * of the migration. Looking at its use, I will propose change of names, but it is just a suggestion. The functions don't just set the channel, they do the migration. migration_proccess_outgoing() migration_proccess_incoming()? No, the naming for incoming was right, the one for outgoing was not. And yes, I understand that one is asynchrconous. This is why it is just a suggestion. Sorry for not being able to came with better naming. Later, Juan.