Re: [Qemu-devel] [PATCH] Support 'help' as a synonym for '?' in command line options

[Markus Armbruster]

Eric Blake <address@hidden> writes:

> On 07/09/2012 06:10 AM, Peter Maydell wrote:
>> On 9 July 2012 13:07, Eric Blake <address@hidden> wrote:
>>> That is, we are filtering based on the explicit presence of a literal
>>> '?' in the help output to determine whether we can further filter based
>>> on '-device device,?' queries without confusing qemu or libvirt;
>>> changing the 'help' output means that old libvirt with new qemu won't
>>> run the extra queries (as if it had been targeting qemu 0.12.x), even
>>> though the older spelling of the query would still work.
>>>
>>> If that is not a concern (that is, if you are willing to state that use
>>> of newer qemu is intended to be coupled with newer libvirt that has been
>>> taught to use 'help' instead of '?'), then this patch is probably fine.
>> 
>> My personal position would be that people who parse -help
>> output deserve to get bitten, but I don't get to make that
>> call :-)
>
> Obviously, newer libvirt can just proceed to try '-device device,help'
> rather than attempting to parse -h output in the first place (that is,
> making this change will not cause undue grief to libvirt 0.10.0, because
> it's a very short patch to teach libvirt.git to parse this new scheme,
> even without relying on -h output).  That is, my concern is not about
> what future libvirt will be fixed to do, but about the existing
> interaction of old libvirt with qemu (libvirt 0.9.13 + qemu 1.2 would
> fail to take full advantage of the qemu 1.2 features because of the
> change in the -h output that libvirt 0.9.13 was hard-coded to expect).
>
> And yes, I agree that libvirt has been bitten more than once because it
> tries to parse unstable -h output, but that is only because qemu has
> never provided anything more stable and more machine-parseable than -h
> output, even though the topic has come up several times in the past.
> For example, we still don't have a way to run 'query-commands' to see
> what the QMP monitor will support without first creating a dummy guest.

Yes, several attempts to provide something real & useful have been shot
down in favor of something hypothetical & perfect.

Thus, libvirt has no choice but working with the (poor) tools we give
it: version number, try and see whether it fails, help output.

Try and see can be slow, and there have been cases where you can't
easily see whether it fails.

Version number breaks down for backports.

Help breaks down when the help text changes.

Perhaps the following could reduce breakage.  Say the feature to be
tested appeared in fully usable form in upstream version X.  If the
version number is at least X, assume we have the feature.  Else, if
detecting a backport of the feature is worth it, check the help output
for a feature signature.  That way, your feature test becomes immune to
future help changes.  Downside, it becomes vulnerable to features
vanishing in the future.  But QEMU shouldn't do that to you without
sufficient prior notice.