[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: [PATCH 3/8] Add QBuffer
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] Re: [PATCH 3/8] Add QBuffer |
Date: |
Tue, 18 May 2010 14:27:15 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
Jan Kiszka <address@hidden> writes:
> Avi Kivity wrote:
>> On 05/17/2010 10:57 AM, Jan Kiszka wrote:
>>> Avi Kivity wrote:
>>>
>>>> On 05/17/2010 10:40 AM, Jan Kiszka wrote:
>>>>
>>>>>> The alternative is to have a schema. Sun RPC/XDR doesn't carry any type
>>>>>> information (you can't even distinguish between a number and text) yet C
>>>>>> clients have to problem extracting typed information from it.
>>>>>>
>>>>>> Having __class__ everywhere means we're carrying the schema in every
>>>>>> message instead of just once.
>>>>>>
>>>>>>
>>>>> The device_show command is already an example where you don't have a
>>>>> predefined schema. It is derived from the data stream the encodes the
>>>>> vmstate fields. So far we have no collision between base64-encoded
>>>>> buffers and real strings, but this may actually change when we start
>>>>> annotating the fields with symbolic constants.
>>>>>
>>>>>
>>>> What is the receiver to do with it?
>>>>
>>>> If it doesn't know the schema (and there is no schema), then all it can
>>>> do is display the key/values. If it does know the schema, then
>>>> __class__ is unnecessary.
>>>>
>>> There is a schema describing the fields (name, size, number of
>>> elements),
>>
>> 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?
>>> 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.
[...]
- Re: [Qemu-devel] [PATCH 3/8] Add QBuffer, (continued)
- Re: [Qemu-devel] [PATCH 3/8] Add QBuffer, Avi Kivity, 2010/05/17
- [Qemu-devel] Re: [PATCH 3/8] Add QBuffer, Jan Kiszka, 2010/05/17
- [Qemu-devel] Re: [PATCH 3/8] Add QBuffer, Avi Kivity, 2010/05/17
- [Qemu-devel] Re: [PATCH 3/8] Add QBuffer, Jan Kiszka, 2010/05/17
- [Qemu-devel] Re: [PATCH 3/8] Add QBuffer, Avi Kivity, 2010/05/17
- [Qemu-devel] Re: [PATCH 3/8] Add QBuffer, Avi Kivity, 2010/05/17
- [Qemu-devel] Re: [PATCH 3/8] Add QBuffer, Jan Kiszka, 2010/05/17
- [Qemu-devel] Re: [PATCH 3/8] Add QBuffer, Avi Kivity, 2010/05/17
- [Qemu-devel] Re: [PATCH 3/8] Add QBuffer, Jan Kiszka, 2010/05/17
- [Qemu-devel] Re: [PATCH 3/8] Add QBuffer, Avi Kivity, 2010/05/17
- Re: [Qemu-devel] Re: [PATCH 3/8] Add QBuffer,
Markus Armbruster <=
- Re: [Qemu-devel] Re: [PATCH 3/8] Add QBuffer, Avi Kivity, 2010/05/18
- [Qemu-devel] Re: [PATCH 3/8] Add QBuffer, Anthony Liguori, 2010/05/17
- Re: [Qemu-devel] Re: [PATCH 3/8] Add QBuffer, Markus Armbruster, 2010/05/18
[Qemu-devel] Re: [PATCH 0/8] Basic device state visualization, Avi Kivity, 2010/05/14
Re: [Qemu-devel] [PATCH 0/8] Basic device state visualization, Anthony Liguori, 2010/05/14
Re: [Qemu-devel] [PATCH 0/8] Basic device state visualization, Blue Swirl, 2010/05/14