1. 15 1月, 2018 12 次提交
  2. 29 10月, 2017 2 次提交
  3. 24 10月, 2017 9 次提交
  4. 22 9月, 2017 9 次提交
  5. 06 9月, 2017 2 次提交
  6. 04 9月, 2017 1 次提交
  7. 02 8月, 2017 1 次提交
    • M
      migration: fix small leaks · b91bf5e4
      Marc-André Lureau 提交于
      Spotted thanks to valgrind and tests/device-introspect-test:
      
      ==11711== 1 bytes in 1 blocks are definitely lost in loss record 6 of 14,537
      ==11711==    at 0x4C2EB6B: malloc (vg_replace_malloc.c:299)
      ==11711==    by 0x1E0CDBD8: g_malloc (gmem.c:94)
      ==11711==    by 0x1E0E696E: g_strdup (gstrfuncs.c:363)
      ==11711==    by 0x695693: migration_instance_init (migration.c:2226)
      ==11711==    by 0x717C4B: object_init_with_type (object.c:344)
      ==11711==    by 0x717E80: object_initialize_with_type (object.c:375)
      ==11711==    by 0x7182EB: object_new_with_type (object.c:483)
      ==11711==    by 0x718328: object_new (object.c:493)
      ==11711==    by 0x4B8A29: qmp_device_list_properties (qmp.c:542)
      ==11711==    by 0x4A9561: qmp_marshal_device_list_properties (qmp-marshal.c:1425)
      ==11711==    by 0x819D4A: do_qmp_dispatch (qmp-dispatch.c:104)
      ==11711==    by 0x819E82: qmp_dispatch (qmp-dispatch.c:131)
      Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
      Message-Id: <20170801160419.14180-1-marcandre.lureau@redhat.com>
      Reviewed-by: NPeter Xu <peterx@redhat.com>
      Reviewed-by: NJuan Quintela <quintela@redhat.com>
      Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
      b91bf5e4
  8. 24 7月, 2017 4 次提交
    • M
      migration: Use JSON null instead of "" to reset parameter to default · 01fa5598
      Markus Armbruster 提交于
      migrate-set-parameters sets migration parameters according to is
      arguments like this:
      
      * Present means "set the parameter to this value"
      
      * Absent means "leave the parameter unchanged"
      
      * Except for parameters tls_creds and tls_hostname, "" means "reset
        the parameter to its default value
      
      The first two are perfectly normal: presence of the parameter makes
      the command do something.
      
      The third one overloads the parameter with a second meaning.  The
      overloading is *implicit*, i.e. it's not visible in the types.  Works
      here, because "" is neither a valid TLS credentials ID, nor a valid
      host name.
      
      Pressing argument values the schema accepts, but are semantically
      invalid, into service to mean "reset to default" is not general, as
      suitable invalid values need not exist.  I also find it ugly.
      
      To clean this up, we could add a separate flag argument to ask for
      "reset to default", or add a distinct value to @tls_creds and
      @tls_hostname.  This commit implements the latter: add JSON null to
      the values of @tls_creds and @tls_hostname, deprecate "".
      
      Because we're so close to the 2.10 freeze, implement it in the
      stupidest way possible: have qmp_migrate_set_parameters() rewrite null
      to "" before anything else can see the null.  The proper way to do it
      would be rewriting "" to null, but that requires fixing up code to
      work with null.  Add TODO comments for that.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      01fa5598
    • M
      migration: Unshare MigrationParameters struct for now · 1bda8b3c
      Markus Armbruster 提交于
      Commit de63ab61 "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 de63ab61, 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: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      1bda8b3c
    • M
      migration: Add TODO comments on duplication of QAPI_CLONE() · e87fae4c
      Markus Armbruster 提交于
      qmp_query_migrate_parameters() and qmp_migrate_set_parameters()
      effectively duplicate QAPI_CLONE() inline.  Add suitable TODO
      comments.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      e87fae4c
    • M
      migration: Clean up around tls_creds, tls_hostname · 8cc99dcd
      Markus Armbruster 提交于
      Optional MigrationParameters members tls_creds and tls_hostname can't
      actually be absent outside qmp_migrate_set_parameters() since commit
      4af245dc (v2.9.0).
      
      Note that commit 4af245dc reverted the part of commit de63ab61 (v2.8.0)
      that made tls_creds and tls_hostname absent instead of "" in the value
      of query-migrate-parameters, even though commit de63ab61 called that a
      mistake.  What a mess.
      
      Drop the redundant tests for presence, and update documentation.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
      8cc99dcd