On 02/24/2017 03:06 PM, Eric Blake wrote: > > Also for 2.9: turn on the deprecation warning for QemuOpts negative > sugar, but leave positive sugar unchanged (it seems like positive sugar > is probably more in use than negative sugar, other than chardev nowait).
Capturing the gist of an IRC conversation: Right now, it appears that '-chardev nowait' is in heavy use ('git grep nowait' shows that qemu itself recommends it in documentation, nodelay being another one). Right now, QemuOpts says that '-chardev wait,nowait' results in 'wait=off', and '-chardev nowait,wait' results in 'wait=on' (that is, last-one-wins semantics) - but in reality, there are probably few (if any) clients that rely on this particular semantics. If we get rid of 'noFOO' magic, we can still teach the chardev QemuOpts to recognize optional keys for BOTH 'wait' and 'nowait'; a user that specifies neither gets the default behavior as always; a user that specifies only 'wait' or 'nowait' gets the requested behavior (although now chardev has to check both key spellings rather than one), and a user that specifies 'wait,nowait' or 'nowait,wait' causes an error, not at QemuOpts parse time, but in the chardev initialization code. That is, for any boolean option where 'noFOO' magic is currently handled by QemuOpts, we can still mostly keep back-compat by adding a new 'noFOO' key to the object, and teaching that object to check that 'FOO' and 'noFOO' are not both selected at once. But whether this change to QemuOpts is the right thing to do is not 2.9 material, so let's take a breather and revisit it for 2.10 (or whenever we try to fix QemuOpts to layer on top of keyval_parse()). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature