Re: [Qemu-devel] Re: [RFC][PATCH v1 00/11] QEMU Guest Agent: QMP-based host/guest communication (virtagent)

[Michael Roth <mdroth@linux.vnet.ibm.com>]

On 03/25/2011 05:03 PM, Anthony Liguori wrote:
> On 03/25/2011 03:42 PM, Michael Roth wrote:
>> On 03/25/2011 02:47 PM, Michael Roth wrote:
>>> These apply on top of Anthony's glib tree, commit
>>> 03d5927deb5e6baebaade1b4c8ff2428a85e125c currently, and can also be
>>> obtained from:
>>> git://repo.or.cz/qemu/mdroth.git qga_v1
>>>
>>> The QGA-specific patches are in pretty rough shape, and there are
>>> some outstanding issues that I'll note below. I just wanted to put
>>> the general approach out there for consideration. Patch-level
>>> comments/review are still much-appreciated though.
>>>
>>> However, patches 1-5 are general json/QAPI-related fixes. Anthony,
>>> please consider pulling these into your glib tree. The json fix-ups
>>> may need further evaluation, but I'm confident they're at least an
>>> improvement. The QAPI ones are trivial fix-ups.
>>>
>>> ISSUES/TODOS:
>>>
>>> - QMP's async callbacks expect the command results to be
>>> de-marshalled beforehand. This is completely infeasible to attempt
>>> outside of the code generator, so this is a big area that needs to be
>>> addressed. So for now, only the 'guest-ping' command works, since it
>>> has no return value. The dummy "guest-view-file" command will cause
>>> an error to be reported to the client.
>>
>> Well, not completely de-marshalled.
>
> I don't follow. Are you talking about async callbacks within QEMU?
> Because that should be totally transparent to you. You'll receive a
> qobject and you can do whatever you need with it.
>

Heh, I was terribly confused when I initially noted that issue...must've 
been looking at a function further up the return chain and convinced 
myself something outside qmp was expected to de-marshal, but that was 
handled elsewhere in qmp-marshal.c

The follow-up was with regard to the much-lesser issue of dealing with 
something like:

static void qmp_guest_view_file_cb(void *qmp__opaque, QObject 
*qmp__retval, Error *qmp__err)

The generated code expects that to be a QObject of a certain type. On 
the QmpProxy side, we have a response from the guest in the form of a 
qdict, with the retval stored with the "return" key:

{ "return": <json/qobject of some type> }

So you need to pull <object of some type> out to pass to the callback. I 
was under the impression that there was no generic qdict_get(), and that 
you were expected to know the type in advance. But...

>> Basically just need a way to pull whatever is stored in the response
>> qdict's "return" field out without specifying the QTYPE in advance...
>> which exists in qdict.c:qdict_get_obj(), it's just not currently
>> exposed to outside callers.
>
> Just use qdict_get()--but I still don't understand what the problem is.

Argh! So that solves the "problem" completely. Thanks :)

>
> Regards,
>
> Anthony Liguori