"Daniel P. Berrange" <berra...@redhat.com> 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 <dgilb...@redhat.com>
> Signed-off-by: Daniel P. Berrange <berra...@redhat.com>
> ---
> 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.
