qemu-devel
[Top][All Lists]
Advanced

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

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


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.




reply via email to

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