From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33358) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WLGto-0007yJ-9g for qemu-devel@nongnu.org; Wed, 05 Mar 2014 13:50:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WLGti-000545-Sx for qemu-devel@nongnu.org; Wed, 05 Mar 2014 13:50:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50059) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WLGti-00053s-Cd for qemu-devel@nongnu.org; Wed, 05 Mar 2014 13:50:30 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s25IoPRd002099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 5 Mar 2014 13:50:25 -0500 Message-ID: <531771EE.2000309@redhat.com> Date: Wed, 05 Mar 2014 11:50:22 -0700 From: Eric Blake MIME-Version: 1.0 References: <1393912317-26221-1-git-send-email-akong@redhat.com> <1393912317-26221-3-git-send-email-akong@redhat.com> <53164D9C.4080500@redhat.com> <20140305064014.GD2669@amosk.info> <53174994.4010606@redhat.com> In-Reply-To: <53174994.4010606@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fEctrMew0IdUVwqh9926OIhNFrjx3tef2" Subject: Re: [Qemu-devel] [libvirt] [PATCH v3 2/2] query-command-line-options: query all the options in qemu-options.hx List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Amos Kong Cc: libvir-list@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fEctrMew0IdUVwqh9926OIhNFrjx3tef2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/05/2014 08:58 AM, Eric Blake wrote: > On 03/04/2014 11:40 PM, Amos Kong wrote: >=20 >>> but the docs imply that I should now see: >>> >>> {"parameters": [], "option": "smbios", "argument": true} >> >> I really got : {"parameters": [], "option": "smbios", "argument": true= } >> >> (I was testing with latest qemu upstream + my patches, attached the >> output file) >=20 > Hmm, maybe I was testing a stale binary. Let me try re-running tests o= n > my end - I recently changed my choice of configure arguments to speed u= p > build time by building fewer binaries, so maybe I tested on a binary > that my configure arguments no longer rebuild. Aha, it WAS my configure options at fault. Apologies for the mis-test on my side. I can now confirm that pre-patch, I see (rearranged a subset of entries, and newlines added for legibility): {"parameters": [], "option": "smbios"}, {"parameters": [{"name": "file", "type": "string"}, {"name": "events", "type": "string"}], "option": "trace"}, and no fips, while post-patch, I see: {"parameters": [], "option": "enable-fips", "argument": false}, {"parameters": [], "option": "smbios", "argument": true}, {"parameters": [{"name": "file", "type": "string"}, {"name": "events", "type": "string"}], "option": "trace"}, which matches the docs. However, I did notice that pre-patch, I see: {"parameters": [], "option": "acpi"} while post-patch, there is no hit for "acpi", but there is a new: {"parameters": [], "option": "acpitable", "argument": true} What's going on there? It is a potential regression if we fail to list an option post-patch that was listed pre-patch. Then again, looking at the actual -help text, I see my particular qemu binary mentions only "-acpitable [sig=3Dstr]..." in the help text (pre- and post-patch), as well as this test to prove there is no '-acpi': $ ./x86_64-softmmu/qemu-system-x86_64 -acpi qemu-system-x86_64: -acpi: invalid option $ ./x86_64-softmmu/qemu-system-x86_64 -acpitable qemu-system-x86_64: -acpitable: requires an argument so it looks like your patch was silently fixing a bug. Indeed, reading vl.c, I see: case QEMU_OPTION_acpitable: opts =3D qemu_opts_parse(qemu_find_opts("acpi"), optarg, = 1); if (!opts) { exit(1); } do_acpitable_option(opts); so the option table named "acpi" is indeed for the command line argument "acpitable". It would be nice to mention bonus bug fixes like that in the commit message (that is, you are not only adding support for flags like -enable-fips, you are also fixing options to match their actual command-line spelling rather than an alternate name associated with the option table in use by the command). So, at this point, we still need a v4 to avoid the duplicate static tables, but I am now set up to give a Tested-by. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --fEctrMew0IdUVwqh9926OIhNFrjx3tef2 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTF3HuAAoJEKeha0olJ0NqM9QIAIK3csaEsR/eQD5Ckr/SHkXe HNnDAU+2KA2FgwYsmDZlLcAwrPk3KjT8hUlhLjFf4+49buakDTT6HMqL+/xGnmG7 IL9nHNmQHgFQH5kEvFqhmGajgSQq9zQArVl+47edcn4elvSlx7e2rL732cNXvd+q LvaNS4BIj/VZQvDWShakGdJdRy8JdN2/LZH67x/OiCPyD2ORXXc8yiI+1cPqUBF6 F+byY9haZ1ksiAs3JylngvMPx1DsUcbD53R0kIJunyNI6Jmp4Nlcga+TbjgPj+dt t+1Bs/DVM8K6ipnA9N8VTHBS3Sr1W4OF4BuVnQeyr5WfrNLrnN+oLBLGwadPTHE= =KRz9 -----END PGP SIGNATURE----- --fEctrMew0IdUVwqh9926OIhNFrjx3tef2--