qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org,
	mdroth@linux.vnet.ibm.com, jyang@redhat.com,
	lcapitulino@redhat.com, Amos Kong <akong@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] monitor: introduce query-config-schema
Date: Mon, 22 Apr 2013 17:16:02 +0200	[thread overview]
Message-ID: <51755432.1040700@redhat.com> (raw)
In-Reply-To: <51755075.1000008@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 22/04/2013 17:00, Eric Blake ha scritto:
> On 04/22/2013 06:07 AM, Paolo Bonzini wrote:
>> Il 22/04/2013 13:48, Amos Kong ha scritto:
>>>>>>> Libvirt doesn't have a stable way to know option
>>>>>>> support detail. This patch introdued a new qmp command
>>>>>>> to query configuration schema information. hmp command
>>>>>>> isn't added.
>>>>> 
>>>>> Can you introspect QemuOpts instead?  All new options are
>>>>> added there.
>>> 
>>> It would be exact to use QemuOpts. I tried to output the
>>> vm_config_groups[] in qemu-config.c, but it seems not enough.
>>> (desc list of -netdev, -drive, -device are all empty)
>> 
>> That's expected because they are parsed otherwise, depending on
>> the backend type.  -chardev is currently working but it's an
>> implementation detail.
> 
> Libvirt cares most about newly added options, which should use
> qemuOpts all the way.  We can understand that legacy options like
> -netdev might not yet use qemuOpts, but they are also legacy
> options, and therefore libvirt can already assume they exist since
> at least qemu 1.3 (when libvirt switched over to QMP probing).  If
> we later add a new feature to -netdev, we should also convert
> -netdev to qemuOpts at that time, so that libvirt would know
> whether the new feature is available.

- -netdev is not a legacy option.  -netdev/-drive/-device do use
QemuOpts, but not for validation.  They create an object, and let the
object parse the option.

They are more complex than the other option, and need a different kind
of introspection (on the properties of a class, or something like that).

Paolo

> At any rate, we really DO want introspection, and having it in 1.5
> is a worthwhile goal.  Even if the introspection turns up empty on
> legacy options, having it for the sake of new options is worth the
> effort.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRdVQyAAoJEBvWZb6bTYbyopcP/jE5TX/NziMeXmXmSS+GFn4G
4SH+4XckjZZPe2ZnpshvkWi1OrbsK0CKw9nk4xcZRFmUFnIZ4T1J2VBXodnATvKZ
+r6yqvOCuoleWQBlnN8OJm/I5kil5UkztiUSsDbgYyP2D4pr3Z7+uGX7ju/4oGCK
qEASGYRsGFItvKkjfUDL2UjBv3dnDerWSPj9IsD/sFajGqcBrvfbGK8YeOG7YvQF
Tinv5dhHg9dpnTJ/fwmw0xr3BmgzLf4fT16I73ErG1INOBjWSUPkQ0h8UeydJEJq
nvpj3/zlqqJdSNxZXU1FRP+stQN2hHDZsTXhKuY+2kbDFRqpwB8WG94TEbOdx6gr
fyNHfueWIByylmQNgbvBCyR2hVI+RipgGHfQ6slTcMMu2pZpZ1m9vWfZF8bvAS+p
NL4+Rf+Ic4uMKZnS6GvD15px0ugGPIcDdwX7YgVqjNMIRZhKFiOf9HYnUfJstQpN
WrEpcnyE4p0JzkO27Otezoz+RTpJ8HaKHvnsbM49BDlWDMme7jKveymWnCyeJxib
g7Hz7V7M76LK0Mlcn66PYctF6JVZP25hC3p3poYbm2F9Duvwg78+b53O6k1XN0sP
/kuZfYWrWRr6sx+/oN6HWMP5q60jRVYKUOYcNOriWS+6Yi8xohFvqQVu4qmycXOG
3HBqamagi+JNMiiO9cx/
=4p7B
-----END PGP SIGNATURE-----

  reply	other threads:[~2013-04-22 15:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-19  9:52 [Qemu-devel] [PATCH] monitor: introduce query-config-schema Amos Kong
2013-04-19 12:02 ` Osier Yang
2013-04-19 12:22   ` Eric Blake
2013-04-19 13:44   ` Osier Yang
2013-04-19 12:39 ` Eric Blake
2013-04-19 13:50   ` Osier Yang
2013-04-19 15:21 ` Paolo Bonzini
2013-04-22 11:48   ` Amos Kong
2013-04-22 12:07     ` Paolo Bonzini
2013-04-22 15:00       ` Eric Blake
2013-04-22 15:16         ` Paolo Bonzini [this message]
2013-04-23  2:40           ` Amos Kong
2013-04-23 13:20         ` Luiz Capitulino
2013-04-23 15:32           ` Eric Blake
2013-04-23 16:55             ` Luiz Capitulino

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=51755432.1040700@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=akong@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=eblake@redhat.com \
    --cc=jyang@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).