[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 05/27] qapi: add SIZE type parser to string_inpu
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH 05/27] qapi: add SIZE type parser to string_input_visitor |
Date: |
Thu, 19 Dec 2013 16:46:37 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130923 Thunderbird/17.0.9 |
Il 19/12/2013 16:40, Michael S. Tsirkin ha scritto:
> On Thu, Dec 19, 2013 at 04:31:41PM +0100, Paolo Bonzini wrote:
>> Il 19/12/2013 15:40, Michael S. Tsirkin ha scritto:
>>> On Mon, Nov 25, 2013 at 09:43:48AM -0700, Eric Blake wrote:
>>>> On 11/25/2013 09:32 AM, Paolo Bonzini wrote:
>>>>
>>>>>> Yes please. Firing up a calculator to figure out how much is 1G is not
>>>>>> friendly, neither is firing it up to figure out what did management do
>>>>>> with QMP. It should be a text based interface not a binary one.
>>>>
>>>> Right now, QMP takes an 'int', which does not allow a suffix. Libvirt
>>>> prefers passing a value in 'bytes', rather than risking confusion on
>>>> whether a value in G was rounded (up, down? to nearest power of 10 or
>>>> power of 2?). Unfortunately, yes, that means you need a calculator when
>>>> parsing QMP logs to see whether the 1073741824 passed by libvirt is the
>>>> 1G you had in mind.
>>>>
>>>> HMP, qtest, and any other decent shell around raw QMP is more than
>>>> welcome to provide human-usable wrappers that takes "1G" as a string and
>>>> turns it into the raw int used by the underlying QMP. In fact, I
>>>> encourage it.
>>>
>>> How will it know 1G is not e.g. an ID?
>>
>> Because all properties are associated to a name. In the case of a
>> memory device, the name could be "size" or "id". When requesting the
>> id, QEMU will use visit_type_str. When requesting the size, QEMU will
>> use visit_type_size. Different functions are called, and the different
>> functions accept different input.
>
> QEMU can do this, but if you want a frontend with QMP as backend,
> it won't.
> So you end up re-implementing this logic in all frontends:
> instead of just passing on properties they need to know
> where 1G is a number and where it's a name.
You have schema introspection that lets you know if a property is an int
or a size.
OptsVisitor chose to accept 1G, but this absolutely need not be
universal. Human interfaces must not be designed according to QEMU's
own whims. Another front-end may want to differentiate 1GB from 1GiB, a
graphical front-end may want to present different widgets; they can do
it because they see "size" in the schema but in any case the "final"
communication to QEMU via QMP will be an int.
Paolo