On 02/02/2018 09:25 AM, Eduardo Habkost wrote: >>> Markus, Eric: from the QAPI point of view, is it OK to remove >>> fields between QEMU versions, as long as we follow our >>> deprecation policy? >> >> I would expect that to not be OK. A fully backwards compatible way to >> deal with this would just be to add a flag to the query-cpus command >> eg something like >> >> query-cpus arch-specific=false >> >> to turn off all this arch specific state, and just report the cheap >> generic info. If it defaults to arch-specific=true when omitted, then >> there's no compat problems. > > This would work, too. I would name it "full-state", > "extended-state" or something similar, though. Not all > arch-specific data is expensive to fetch, and not all > non-arch-specific data is unexpensive. > > But I'd like to confirm if it's OK to make existing non-optional > struct fields optional in the QAPI schema. Markus, Eric?
If you add an optional bool/enum to opt-in to the command in order to provide different levels of reporting on output, and the default remains that when the new input field is absent, all information that was output in earlier versions of qemu is still output, then you are backwards compatible. This is true even if you switched some fields from mandatory output to optional output, because of the use of the new input flag for opt-in semantics. Newer callers that use the opt-in field get what they want, older callers get what they always expected. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
