|
From: | Avi Kivity |
Subject: | [Qemu-devel] Re: [PATCH 3/8] Add QBuffer |
Date: | Mon, 17 May 2010 12:29:20 +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/17/2010 12:17 PM, Jan Kiszka wrote:
Avi Kivity wrote:On 05/17/2010 11:55 AM, Jan Kiszka wrote: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.For that use case, I agree. Maybe we should send both the parsed and unparsed information.Now I can't parse what you mean.
Sorry. I meant that if we have a raw buffer that we can decode (like pci config space and its fields) maybe it makes sense to send both formats. The raw buffer is something likely to be stable, and the decoded fields are more readable. But I realize now that doesn't make sense in the context of base64 encoding which started all this.
But if the client isn't going to interpret the object and only display it, then there is no need for __class__?For that uncommon case, yes. But the common one is to perform a bit more than raw JSON dictionary printing.
But the common one is likely to know the type of the object beforehand (or it can't do much beyond printing, since it has no idea what fields to expect).
-- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
[Prev in Thread] | Current Thread | [Next in Thread] |