On 03/07/2011 04:56 PM, Anthony Liguori wrote:
On 03/07/2011 04:49 PM, Michael Roth wrote:
It's not really inventing anything. We've always started off with
qobject params, which we then pulled apart and stuck into xmlrpc
params, which when then turned into xml for transport. Now we just
take the qobjects and covert them to json directly. We've only cut out
an intermediate library and switched to a different UTF8-based
encoding for transport.
With QAPI we'd have the extra step of pulling function parameters into
a qobjects. Not any different from what the situation would've been
using xmlrpc or any of the other binary encoding that were considered.
It does look more similar to what QMP/QAPI is doing than previously,
but it doesn't need to be all or nothing.
I think I have a Clever Idea here but hacking together a prototype.
Basic thinking is to make guest commands part of the QMP namespace such
that a guest command looks like any other QMP command. The only role
QEMU plays in this model is validating the commands inputs and outputs
and then passing the command to the guest agent.
Hmm...this does sound nice. But keep in mind that not all parameters
passed in via QMP were intended solely for the guest. That just
happens to be the case for the RPCs we have implemented in this RFC.
For instance, one of QMP commands we intended to add for the new
getfile implementation, to address concerns over a hardcoded file size
limit while avoiding large memory allocations on the host or guest,
was chunked file transfer using a set of stateful RPCs, with a higher
level QMP command to wrap them:
qmp.getfile <local file> <remote file>
Where <local file> could be a normal file, or "-" for direct output to
monitor. Internally, the set of actual RPCs being executed are much
lower level. Something like:
offset = 0
local_fd = open(<local file>)
remote_fd = va.open(<remote file>)
while (((read_count, buf) = va.read(remote_fd, offset, 512*1024)) > 0):
write(local_fd, buf, read_count)
offset += read_count
va.close(remote_fd)
Any higher-level commands of this type would be still doable, but
would need to be pushed all the way up to the management stack, or
done programatically, so it does limit what can be done within an
interactive shell. Some might argue that's for the best, but there may
be more of a trade-off in other possible use cases.
Stay tuned.
Regards,
Anthony Liguori
Regards,
Anthony Liguori