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
