Skip to content
Snippets Groups Projects
  1. Oct 02, 2021
  2. Aug 26, 2021
  3. Aug 10, 2021
  4. Aug 03, 2021
  5. Jul 12, 2021
  6. Apr 20, 2021
  7. Mar 23, 2021
  8. Mar 17, 2021
  9. Mar 06, 2021
  10. Mar 05, 2021
  11. Jan 28, 2021
  12. Jan 23, 2021
  13. Dec 21, 2020
  14. Dec 19, 2020
    • Markus Armbruster's avatar
      qobject: Change qobject_to_json()'s value to GString · eab3a467
      Markus Armbruster authored
      
      qobject_to_json() and qobject_to_json_pretty() build a GString, then
      covert it to QString.  Just one of the callers actually needs a
      QString: qemu_rbd_parse_filename().  A few others need a string they
      can modify: qmp_send_response(), qga's send_response(), to_json_str(),
      and qmp_fd_vsend_fds().  The remainder just need a string.
      
      Change qobject_to_json() and qobject_to_json_pretty() to return the
      GString.
      
      qemu_rbd_parse_filename() now has to convert to QString.  All others
      save a QString temporary.  to_json_str() actually becomes a bit
      simpler, because GString provides more convenient modification
      functions.
      
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20201211171152.146877-6-armbru@redhat.com>
      eab3a467
    • Eric Blake's avatar
      qapi: Use QAPI_LIST_PREPEND() where possible · 54aa3de7
      Eric Blake authored
      
      Anywhere we create a list of just one item or by prepending items
      (typically because order doesn't matter), we can use
      QAPI_LIST_PREPEND().  But places where we must keep the list in order
      by appending remain open-coded until later patches.
      
      Note that as a side effect, this also performs a cleanup of two minor
      issues in qga/commands-posix.c: the old code was performing
       new = g_malloc0(sizeof(*ret));
      which 1) is confusing because you have to verify whether 'new' and
      'ret' are variables with the same type, and 2) would conflict with C++
      compilation (not an actual problem for this file, but makes
      copy-and-paste harder).
      
      Signed-off-by: default avatarEric Blake <eblake@redhat.com>
      Message-Id: <20201113011340.463563-5-eblake@redhat.com>
      Reviewed-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Acked-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      [Straightforward conflicts due to commit a8aa94b5 "qga: update
      schema for guest-get-disks 'dependents' field" and commit a10b453a
      "target/mips: Move mips_cpu_add_definition() from helper.c to cpu.c"
      resolved.  Commit message tweaked.]
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      54aa3de7
  15. Dec 10, 2020
  16. Nov 18, 2020
  17. Nov 16, 2020
    • Michael Roth's avatar
      qga: update schema for guest-get-disks 'dependents' field · a8aa94b5
      Michael Roth authored
      
      The recently-added 'guest-get-disk' command returns a list of
      GuestDiskInfo entries, which in turn have a 'dependents' field which
      lists devices these entries are dependent upon. Thus, 'dependencies'
      is a better name for this field. Address this by renaming the field
      accordingly.
      
      Additionally, 'dependents' is specified as non-optional, even though
      it's not implemented for w32. This is misleading, since it gives users
      the impression that a particular disk might not have dependencies,
      when in reality that information is simply not known to the guest
      agent. Address this by making 'dependents' an optional field, and only
      marking it as in-use when the facilities to obtain this information are
      available to the guest agent.
      
      Cc: Eric Blake <eblake@redhat.com>
      Cc: Tomáš Golembiovský <tgolembi@redhat.com>
      Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
      Reviewed-by: default avatarEric Blake <eblake@redhat.com>
      Reviewed-by: default avatarMarc-André Lureau <marcandre.lureau@redhat.com>
      Signed-off-by: default avatarMichael Roth <michael.roth@amd.com>
      a8aa94b5
  18. Nov 09, 2020
  19. Nov 03, 2020
  20. Nov 02, 2020
Loading