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
