[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH for-2.10 09/10] migration: Unshare MigrationPara

From: Eric Blake
Subject: Re: [Qemu-block] [PATCH for-2.10 09/10] migration: Unshare MigrationParameters struct for now
Date: Tue, 18 Jul 2017 12:42:46 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

On 07/18/2017 08:41 AM, Markus Armbruster wrote:
> Commit de63ab6 "migrate: Share common MigrationParameters struct"
> reused MigrationParameters for the arguments of
> migrate-set-parameters, with the following rationale:
>     It is rather verbose, and slightly error-prone, to repeat
>     the same set of parameters for input (migrate-set-parameters)
>     as for output (query-migrate-parameters), where the only
>     difference is whether the members are optional.  We can just
>     document that the optional members will always be present
>     on output, and then share a common struct between both
>     commands.  The next patch can then reduce the amount of
>     code needed on input.
> I need to unshare them to correct a design flaw in a stupid, but
> minimally invasive way, in the next commit.  We can restore the
> sharing when we redo that patch in a less stupid way.  Add a suitable
> TODO comment.
> Note that I revert only the sharing part of commit de63ab6, not the
> part that made the members of query-migrate-parameters' result
> optional.  The schema (and thus introspection) remains inaccurate for
> query-migrate-parameters.  If we decide not to restore the sharing, we
> should revert that part, too.
> Signed-off-by: Markus Armbruster <address@hidden>
> ---
>  hmp.c                 |  4 +--
>  migration/migration.c | 12 +++++---
>  qapi-schema.json      | 85 
> ++++++++++++++++++++++++++++++++++++++++++++++-----
>  3 files changed, 87 insertions(+), 14 deletions(-)

No fun, but when you're up against a release deadline, it beats the
alternative of baking in a design flaw longer than we want.

Reviewed-by: Eric Blake <address@hidden>

A possible alternative: make a common base class with most of the
members (those that aren't related to tls), then two subclasses, one
with output semantics, one with input semantics, for the tls members.
You share a bit more code that way (and could still QAPI_CLONE the
common base-class members).

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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