All of lore.kernel.org
 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 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.