Re: [Qemu-devel] [PATCH 2/2] char: report frontend open/closed state in 'query-chardev'

[Eric Blake]

On 05/29/2014 02:43 PM, Laszlo Ersek wrote:

>>> +#                 backend (eg. with the chardev=... option) is in open or
>>> +#                 closed state (since 2.2)
>>
>> Why 2.2? Are you saying it is too late to make the 2.1 soft freeze?
> 
> I thought that reviewers would immediately question the direction of the
> patchset (ie. monitor events + new query field), and not just suggest
> tweaks; so 2.2 seemed safer. Perhaps I can make it till the 2.1 soft
> freeze (June 17th), but that depends (as I've learned now) on Wenchao's
> series too.

Actually, I think your series and Wenchao's are mostly orthogonal -
either could go in first, and it's just fine if one hits 2.1 while the
other waits till 2.2.  It's just a matter of code churn, where getting
both in means whoever is second has to consider the code added in the
meantime (either your series is tweaked to use the qapi generation, or
Wenchao's series is tweaked to convert "one" more event).

> 
>> Why optional?  It is always emitted by your code, so it's simpler to
>> just state that it is now a permanent part of the output struct (no
>> back-compat considerations, since it is an output-only struct).
> 
> I wasn't sure how libvirt would react to an earlier qemu's output struct
> if its parser code expected the new field as mandatory. I didn't
> consider that you could infer this field from the presence of the
> events. So yeah I can make it mandatory.

We already have instances of adding new output fields as always-present
- so the burden is already on management apps to check the QAPI docs of
the oldest version of qemu it is targetting rather than relying on the
newest version of qemu marking things as optional.  I think it's cleaner
to mark output fields as optional only when we know we will be omitting
them conditionally within the current version of qemu (and with no
bearing on how older qemu did things).  Libvirt will already have to
tolerate the field being missing (in fact, if the event doesn't exist,
libvirt shouldn't be expecting the field to be present).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature