qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: [PATCH 3/8] Add QBuffer


From: Avi Kivity
Subject: Re: [Qemu-devel] Re: [PATCH 3/8] Add QBuffer
Date: Tue, 18 May 2010 20:24:59 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4

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.




reply via email to

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