All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Andrea Bolognani <abologna@redhat.com>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC PATCH qemu] qmp: Add qom-list-properties to list QOM object properties
Date: Tue, 23 Jan 2018 22:20:25 +1100	[thread overview]
Message-ID: <20180123112025.GI11419@umbus> (raw)
In-Reply-To: <1516702111.31897.2.camel@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2384 bytes --]

On Tue, Jan 23, 2018 at 11:08:31AM +0100, Andrea Bolognani wrote:
> On Fri, 2018-01-19 at 15:34 +0100, Andrea Bolognani wrote:
> > > > This won't solve the libvirt problem we were discussing, because it
> > > > needs an existing instance of the object.  libvirt wants to know the
> > > > machine properties *without* instantiating an instance.
> > > 
> > > My patch works with types, it creates an instance for a short time itself,
> > > this is why it does not do a thing for "pseries" as it is not a type and
> > > prints properties for the "pseries-2.12-machine" type.
> > 
> > Yeah, I took this for a spin and can confirm that it's pretty much
> > exactly what I was thinking about. The fact that the QMP command
> > instantiates objects behind the scenes is not an issue, at least
> > from libvirt's point of view: device-list-properties does the same
> > thing and we already use it quite happily; what matters is that we
> > can call this, along with all the other capabilities-collecting
> > QMP commands, in one go and on a single QEMU instance.
> 
> David, I know you're busy with linux.conf.au, but it would be
> really helpful if you could carve out five minutes to look over
> Alexey's proposal again, with my reply above in mind, and let us
> know whether it looks a reasonable design. Doesn't have to be a
> review, just a quick feedback on the high-level idea.

It looks ok, I think, but I don't think I'm really the right person to
ask.  I do wonder if creating a throwaway instance could cause
trouble, especially for something like machine that might well have
gotten away with having global side-effects in the past.  I think we
need to talk with someone who knows more about qom and qapi - Markus
seems the obvious choice.

> I'm moving forward with the libvirt implementation of pSeries
> capabilities and I would have to start implementing support for
> this new QMP command, well, pretty much... Right now :) But I'd
> rather not start at all if I'm just going to have to scrap
> everything later.

Yeah, unfortunately because its part of the core infrastructure, not
power specific, this isn't something I can make call on.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2018-01-23 11:22 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-19  5:09 [Qemu-devel] [RFC PATCH qemu] qmp: Add qom-list-properties to list QOM object properties Alexey Kardashevskiy
2018-01-19  5:19 ` David Gibson
2018-01-19  6:15   ` Alexey Kardashevskiy
2018-01-19  6:22     ` Alexey Kardashevskiy
2018-01-19 14:34     ` Andrea Bolognani
2018-01-23 10:08       ` Andrea Bolognani
2018-01-23 11:20         ` David Gibson [this message]
2018-01-23 12:03           ` Andrea Bolognani
2018-01-23 12:49             ` David Gibson
2018-01-23 13:33               ` Andrea Bolognani
2018-01-31  9:03               ` Alexey Kardashevskiy
2018-01-31 17:22                 ` Markus Armbruster
2018-01-31 17:22 ` Markus Armbruster
2018-02-02  2:02   ` Alexey Kardashevskiy
2018-02-02  7:37     ` Markus Armbruster
2018-02-05  3:30       ` Alexey Kardashevskiy
2018-02-07 12:18         ` Andrea Bolognani
2018-02-21  3:36 ` Alexey Kardashevskiy
2018-02-21 10:01   ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180123112025.GI11419@umbus \
    --to=david@gibson.dropbear.id.au \
    --cc=abologna@redhat.com \
    --cc=aik@ozlabs.ru \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.