qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [RFC][PATCH v1 00/11] QEMU Guest Agent: QMP-based h


From: Michael Roth
Subject: Re: [Qemu-devel] Re: [RFC][PATCH v1 00/11] QEMU Guest Agent: QMP-based host/guest communication (virtagent)
Date: Fri, 25 Mar 2011 17:36:50 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]