On 05/18/2010 03:27 PM, Markus Armbruster wrote:
Surely the schema has to describe the type as well? If it does, you can
use the schema to generate a classes at compile time.
Doesn't that tie you to a specific version of QMP at compile-time?
The client needs to ignore anything not provided by the schema to be
forward compatible.
(alternatively we make sure anything new is explicitly enabled by the
client, so it can parse strictly according to the schema).
but their types (int, buffer, sub-field, array of X) are
derived from the JSON objects (ie. the JSON parser does this job).
The names of fields are also type information.
Not in the case of device_show. The clients have no idea of the vmstate
structures before they were transfered. Granted, that will likely remain
a special case in the QMP command set.
qdev device properties are similar. Right now, they occur only as
arguments of device_add. When do_info_qtree() gets converted, they'll
appear in results.
This sounds like a horror movie in the making, "sysfs: the return". The
qdev tree is completely undocumented, so once again the code dictates
the protocol. Any bug in the qdev hierarchy will be hardcoded forever
and ever, or we have to add a new layer of indirection to have a
separate internal qdev and an external qdev-for-qmp tree(s).
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
