qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] qmp_device_add() ret_data argument
@ 2015-09-10  3:08 Programmingkid
  2015-09-10  3:36 ` Eric Blake
  2015-09-10  9:01 ` Markus Armbruster
  0 siblings, 2 replies; 3+ messages in thread
From: Programmingkid @ 2015-09-10  3:08 UTC (permalink / raw)
  To: Peter Maydell; +Cc: qemu-devel qemu-devel

What does the function qmp_device_add() have a ret_data argument if it isn't used? This function is located in qdev-monitor.c.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Qemu-devel] qmp_device_add() ret_data argument
  2015-09-10  3:08 [Qemu-devel] qmp_device_add() ret_data argument Programmingkid
@ 2015-09-10  3:36 ` Eric Blake
  2015-09-10  9:01 ` Markus Armbruster
  1 sibling, 0 replies; 3+ messages in thread
From: Eric Blake @ 2015-09-10  3:36 UTC (permalink / raw)
  To: Programmingkid, Peter Maydell; +Cc: qemu-devel qemu-devel

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

On 09/09/2015 09:08 PM, Programmingkid wrote:
> What does the function qmp_device_add() have a ret_data argument if it isn't used? This function is located in qdev-monitor.c.

[meta-comment - can you teach your mailer to wrap long lines? It's a
pain to reply to something that scrolls off the screen]

Because the function is installed as a command handler callback, and all
command handler callbacks must have the same signature (QDict *, QObject
**, Error **).

Most qapi-fied commands install a generated handler named
qmp_marshal_*() with the requisite signature, that then parses the QDict
* into a nicer breakdown of C parameters to the real handler, then
collect the returned struct back into the QObject for return.  So if you
want to know how to manipulate QDict/QObject directly, look at the
generated qmp-marshal.c for inspiration.

Meanwhile, device_add has not yet been fully qapi-fied.

I'm about to post a series that completes the qapi-fication of
netdev_add, which is somewhat similar to device_add; if you want to look
at that for ideas of what is involved, be my guest (netdev_add had an
incomplete qapi-fication in qapi-schema.json; device_add isn't even
listed there yet so it is even further behind).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Qemu-devel] qmp_device_add() ret_data argument
  2015-09-10  3:08 [Qemu-devel] qmp_device_add() ret_data argument Programmingkid
  2015-09-10  3:36 ` Eric Blake
@ 2015-09-10  9:01 ` Markus Armbruster
  1 sibling, 0 replies; 3+ messages in thread
From: Markus Armbruster @ 2015-09-10  9:01 UTC (permalink / raw)
  To: Programmingkid; +Cc: Peter Maydell, qemu-devel qemu-devel

Programmingkid <programmingkidx@gmail.com> writes:

> What does the function qmp_device_add() have a ret_data argument if it
> isn't used? This function is located in qdev-monitor.c.

QMP command handlers all implement the same interface:

        void (*cmd_new)(QDict *params, QObject **ret_data, Error **errp);

Handlers of commands returning a value store the value to *ret_data.
Handlers of commands not returning a value (such as device_add) leave
ret_data alone.

We could require them to store NULL, but that would be easy to forget,
and usually catastrophic, so we don't.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2015-09-10  9:01 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-09-10  3:08 [Qemu-devel] qmp_device_add() ret_data argument Programmingkid
2015-09-10  3:36 ` Eric Blake
2015-09-10  9:01 ` Markus Armbruster

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).