From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57013) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SoCw4-0001Jo-IQ for qemu-devel@nongnu.org; Mon, 09 Jul 2012 08:19:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SoCw2-0002D4-8c for qemu-devel@nongnu.org; Mon, 09 Jul 2012 08:19:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5084) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SoCw2-0002Cn-0Q for qemu-devel@nongnu.org; Mon, 09 Jul 2012 08:19:26 -0400 Message-ID: <4FFACC49.90102@redhat.com> Date: Mon, 09 Jul 2012 06:19:21 -0600 From: Eric Blake MIME-Version: 1.0 References: <1341834742-28654-1-git-send-email-peter.maydell@linaro.org> <4FFAC994.4060804@redhat.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig2729002B3AEBB516E5E0E2AA" Subject: Re: [Qemu-devel] [PATCH] Support 'help' as a synonym for '?' in command line options List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Blue Swirl , Anthony Liguori , Michael Tokarev , qemu-devel@nongnu.org, patches@linaro.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2729002B3AEBB516E5E0E2AA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/09/2012 06:10 AM, Peter Maydell wrote: > On 9 July 2012 13:07, Eric Blake 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 base= d >> 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 us= e >> of newer qemu is intended to be coupled with newer libvirt that has be= en >> taught to use 'help' instead of '?'), then this patch is probably fine= =2E >=20 > 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. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig2729002B3AEBB516E5E0E2AA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJP+sxJAAoJEKeha0olJ0Nq+zAH+gKqfxHvXrg38Z1mtd+W+ZRv NnG8jVv5iArgMCC26rrScBWzVPNGah8Igd2VWFyT5qwqBXClHMsDH6Pg01RawumK Je/GAVcR2C4sP7HW7uyg5mYnB+iVoMNfRkrJBT768m3xPmX9dgeZo1+V2bvYMhiA zwf4It5ViyppssRY1IL+SujzcGbstSgnDr9fHQO19qcbnahIl2fPzPar55qTelAh 73S5mLCktncStbsIdhcFtKzo4Y5/UGUCuWsm4mOEEMTZt5uJoedpVDTjorGz3YVW H1RjrTMafUPaLfisgLr6MVC3gZoEJJoCyjZtp5sb4b0j692wM9Aw9rVP39RKylw= =3ejR -----END PGP SIGNATURE----- --------------enig2729002B3AEBB516E5E0E2AA--