From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59793) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WNNwn-0007NE-Ds for qemu-devel@nongnu.org; Tue, 11 Mar 2014 10:46:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WNNwh-0003o3-K3 for qemu-devel@nongnu.org; Tue, 11 Mar 2014 10:46:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58377) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WNNwh-0003nl-67 for qemu-devel@nongnu.org; Tue, 11 Mar 2014 10:46:19 -0400 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2BEkHDC016914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 11 Mar 2014 10:46:17 -0400 Message-ID: <531F21B7.6010308@redhat.com> Date: Tue, 11 Mar 2014 08:46:15 -0600 From: Eric Blake MIME-Version: 1.0 References: <1394073416-12578-1-git-send-email-akong@redhat.com> <1394073416-12578-3-git-send-email-akong@redhat.com> <5318E743.7070609@redhat.com> <878usms5a6.fsf@blackfin.pond.sub.org> <531DF93B.7060708@redhat.com> <87y50hw1fr.fsf@blackfin.pond.sub.org> In-Reply-To: <87y50hw1fr.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="c1Mr5hGN4OGwDio6cB8VqUDjnv41Lto2x" Subject: Re: [Qemu-devel] [PATCH v4 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: Markus Armbruster Cc: libvirt-list@redhat.com, qemu-devel@nongnu.org, jyang@redhat.com, lcapitulino@redhat.com, pbonzini@redhat.com, Amos Kong This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --c1Mr5hGN4OGwDio6cB8VqUDjnv41Lto2x Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/11/2014 03:04 AM, Markus Armbruster wrote: >> '-cdrom filename' could easily be re-written [in a >> future qemu version] to use QemuOpts with an implied parameter name >> (we've done that elsewhere, such as for '-machine'). >=20 > Incompatible change for funny filenames: -cdrom you,break=3Dme. Oh. And probably tangentially related to the bug I just reported where '-drive id=3Da,file=3Dfunny,,id=3D1' works, but swapping to '-drive file=3Dfunny,,id=3D1,id=3Da' fails. >=20 > Besides breaking funny filenames, we'd also buy ourselves some stupid > -readconfig / -writeconfig trouble. Let me explain. >=20 > -cdrom F is effectively sugar for "-drive media=3Dcdrom,index=3D2,file=3D= FF", > where FF is F with comma doubled. >=20 > -writeconfig writes out desugared QemuOpts. Therefore, "-cdrom r7.iso"= > gets written as >=20 > [drive] > media =3D "cdrom" > index =3D "2" > file =3D "r7.iso" >=20 > which -readconfig can read. So it sounds like what we REALLY want is a way to tell, for every command line option, what that command will convert to in config notation. 'drive' is output as-is, because it is (currently) a first-class option, while 'cdrom' is sugar. Mentioning that '-cdrom' is valid on the command line is good (especially since if we DO have introspection on what sugar is available, we can remove the sugar in the future and libvirt can still query whether it should use the sugar form or the preferred form when controlling a new qemu); but also mentioning that '-cdrom' is sugar and what the preferred form is would also be good (libvirt can use the information to use preferred forms instead of sugar)= =2E >=20 > If we convert -cdrom to QemuOpts, it gets written out like this: >=20 > [cdrom] > file =3D "r7.iso" >=20 > If we continue to desugar it, it'll *also* get written out as before. > Either we *delete* the sugared QemuOpts to avoid duplication, or we > *stop* desugaring. The latter breaks -readconfig of existing > configuration files, and complicates the code reading configuration fro= m > QemuOpts. >=20 > I don't think any of the old non-QemuOpts options that have become suga= r > for newer, more flexible QemuOpts options should be converted to > QemuOpts. Fair enough. So that means that for every option that exists as sugar for some other option, the introspection should include enough details as to give the end user a hint as to what the sugar will expand to. >=20 >> So your idea of a tri-state (QemuOpts, no argument, or other argument)= >> doesn't add anything - any option that takes "other argument" could be= >> converted to take QemuOpts, and from the command line, we can't tell t= he >> difference from whether something was implemented by QemuOpts, only by= >> whether we have introspection on what the argument consists of. >=20 > I doubt we can convert all existing options to QemuOpts without breakin= g > backward compatibility and complicating the code. Point taken. >> We already know 'query-command-line-options' is not a full introspecti= on >> yet. So far, libvirt has managed to get by on partial information (in= >> fact, the whole hack for special-casing -drive to merge multiple lists= >> together was precisely to avoid a regression with at least providing t= he >> partial information that libvirt was actually using). Documenting tha= t >> QemuOpts information may be incomplete may be nice, but shouldn't hold= >> up the initial purpose of this patch which is to document non-QemuOpts= >> options. And knowing that an option takes unspecified arguments is >> still better than not knowing about the option at all. >=20 > If all we want is a quick fix for "I can't see whether -frobnicate is > supported", then let's add a command to dump qemu_options[], and leave > query-command-line-options broken as designed. >=20 > But if we want proper command line introspection, then let's do it > properly: no quick hacks, no half-truths. The current 'query-command-line-options' is misnamed, it is more like 'query-config-options'. Maybe we want that functionality - but if so, we should name it correctly. Meanwhile, libvirt DOES want a way to query whether -frobnicate is supported, but as we already lack it, not having it in 2.0 won't make a difference, so I agree with delaying this series until 2.1 when we can think more about getting it right rather than fast. >> {"option":"M", "parameters":[], "config-name":"machine", >> "argument": true}, >> {"option":"machine", "parameters":[ >> {"name": "firmware", "help": "firmware image", "type": "string"}, >> {"name": "type", "implied-name": true, "help": "emulated machine", >> "type": "string"}, ...]}, >> >> to make it a bit more obvious that '-M str' and '-machine str' are bot= h >> shorthands for the preferred '-machine type=3Dstr', and that the same >> effect is reached via a config file that has a [machine] section. >=20 > Use case for the introspection into the desugaring of -M? >=20 > Can't cover less trivial desugarings, like -cdrom. Use case for any desugaring is to learn what the preferred form is, and to know that a preferred form exists (in case there are other existing command-line arguments that we convert in the future by adding a new preferred QemuOpts form). But if we express desugaring at all, then we need to fully express it - so we need a schema that shows exactly how cdrom is converted into drive (including both the implied media=3Dcdrom and index=3D2 arguments, as well as the named file=3DFF conversion). >> >> Yes. We've identified at least 3 exceptions now (acpitable, boot, smp= ), >> and exposing those exceptions in the introspection is a good idea, to >> make us quit adding new ones. >=20 > It'll make us quit adding new ones only if we can come up with a test > that breaks when we add new ones :) Too true. >>> Do we care? >>> >>>> This is a bug fix patch, so let's shoot to get it into 2.0. >>> >>> Yes. So far, detecting boolean options like -enable-fips has never worked, so that is out of scope for 2.0. Likewise, the bug between the command line -acpitable and the config file [acpi] not having matching names has been buggy since the query-command-line-options was introduced and hasn't been tripping up libvirt yet, so again rushing a fix may not be the best. >=20 > Is better command line introspection in 2.0 worth the risk that comes > with softening up the hard freeze? At this point, probably not. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --c1Mr5hGN4OGwDio6cB8VqUDjnv41Lto2x 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/ iQEcBAEBCAAGBQJTHyG3AAoJEKeha0olJ0Nq1ZQH/0FAVdoBiyi8PRP/Bywzbfob 4TLH0hT0dsS/8ecQqbyB3SI8xI7q5Y0hXvp4WUSkURLE+h7yN5TFC155kfYJGQpF DvIidBKi2yXe0BdSZPAxPAPRkznULvfQrO106pLg/DPX853nZUx8Nrk7NvczsVwD Szt7OzM9mbBX4rKz8S9gFd/I0Bs0UBm73rcAT9IAo48/UcIVZs1wd9UbkSJgHk/l gDfJikyebiv5tpDjYGXpYHayKu5jEg9ILIUwQqRFsUzYyJ/RiEHaQUGUMCZSYTnT oiQl8IdKEgxrdaU81JoN/FluIc34Flg+ygNxvXq+dtyJ5PQNdB2hcFNsdlYQ1/0= =Zw9a -----END PGP SIGNATURE----- --c1Mr5hGN4OGwDio6cB8VqUDjnv41Lto2x--