From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35761) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SySDD-0000qW-K7 for qemu-devel@nongnu.org; Mon, 06 Aug 2012 14:39:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SySDB-0001Wz-LU for qemu-devel@nongnu.org; Mon, 06 Aug 2012 14:39:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57041) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SySDB-0001WS-Dc for qemu-devel@nongnu.org; Mon, 06 Aug 2012 14:39:29 -0400 Message-ID: <501FF348.7020100@redhat.com> Date: Mon, 06 Aug 2012 10:39:36 -0600 From: Eric Blake MIME-Version: 1.0 References: <1344158004-10370-1-git-send-email-owasserm@redhat.com> <1344158004-10370-3-git-send-email-owasserm@redhat.com> <501FD40E.8030506@redhat.com> <501FEB19.3030007@redhat.com> <501FED67.7070809@redhat.com> <501FF0B4.6040309@redhat.com> In-Reply-To: <501FF0B4.6040309@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigD3A84E05839B3B5BC848BE21" Subject: Re: [Qemu-devel] [PATCH 02/11] Add migrate-set-capabilities and query-migrate-capabilities List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Orit Wasserman Cc: peter.maydell@linaro.org, aliguori@us.ibm.com, quintela@redhat.com, stefanha@gmail.com, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com, blauwirbel@gmail.com, avi@redhat.com, pbonzini@redhat.com, lcapitulino@redhat.com, chegu_vinod@hp.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD3A84E05839B3B5BC848BE21 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 08/06/2012 10:28 AM, Orit Wasserman wrote: >> That is, BOTH commands end up iterating over a list of caps, and outpu= t >> identical information in the case where caps exist of 'name: state' fo= r >> each capability. >> > The information is different: > the first: > MigrationCapabilityStatusList * > qmp_query_migrate_supported_capabilities(Error **errp) > { > MigrationCapabilityStatusList *caps_list =3D g_malloc0(sizeof(*caps= _list)); >=20 > caps_list->value =3D g_malloc(sizeof(*caps_list->value)); > caps_list->value->capability =3D MIGRATION_CAPABILITY_XBZRLE; > caps_list->value->state =3D true; > caps_list->next =3D NULL; >=20 > return caps_list; > } >=20 > the second: > MigrationCapabilityStatusList * > qmp_query_migrate_supported_capabilities(Error **errp) I think you meant this for the second: +MigrationCapabilityStatusList *qmp_query_migrate_capabilities(Error **er= rp) +{ + MigrationCapabilityStatusList *head =3D NULL; + MigrationCapabilityStatusList *caps; + MigrationState *s =3D migrate_get_current(); + int i; + + for (i =3D 0; i < MIGRATION_CAPABILITY_MAX; i++) { + if (head =3D=3D NULL) { + head =3D g_malloc0(sizeof(*caps)); + caps =3D head; + } else { + caps->next =3D g_malloc0(sizeof(*caps)); + caps =3D caps->next; + } + caps->value =3D + g_malloc(sizeof(*caps->value)); + caps->value->capability =3D i; + caps->value->state =3D s->enabled_capabilities[i]; + } > you can look at it as 64bit support one is to know if the processor sup= ports 64 bit > the other to know if the OS uses 64 bit Okay, so the QMP code is currently different (one outputs a list where every entry in the list is hard-coded to true, the other outputs a list where each entry reflects the current state). But that still doesn't address my concern that you don't need two QMP commands. Merely listing 'xbzrle' in the list is enough to know that 'this particular qemu knows how to do xbzrle', and the user is free to ignore the additional information of whether it is actually in use at the time if all the application cared about was determining the set of known capabilities. Given your argument with 64-bit processing, the same reasoning applies - ask for a list of capabilities, and the result will either omit '64bit' (the capability is not possible), include '64bit:false' (the capability is known by the emulator, but not in use by the guest), or include '64bit:true' (the capability is both known and in-use). A user that only cares about querying supported capabilities will check whether '64bit' is in the list, and throw away the information about whether it is on or off (and since the QMP command currently returns a hard-coded true, that information is already being discarded via your query-migrate-supported-capabilities command). That is, your implementation for query-migrate-capabilities is sufficient to satisfy both class of users, without needing query-migrate-supported-capabilities= =2E --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enigD3A84E05839B3B5BC848BE21 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/ iQEcBAEBCAAGBQJQH/NIAAoJEKeha0olJ0NqQsUH/1Z2bOmomU85deUqizEdgzZA SEU3hGllhjzYYK1VfbKYbg8/UPM+0pNYm9Ff2x4w/YCu8va4U2Q+ikf/+z2cuVoI R+WH0vzaN1PX048YJ8BE6g9/7UDJX895gcRpnQcuhyFvZnnm+F4ipxDMPyYDN5Ev g4u3AgmzqLYwFL1O+Zwjcf2CpWODNO51RUoRL6S2iY6hbyBjEM7dIN4a8YmTXrV9 84ODxXisy0YA7/pzAB1e33ufRdAFvKfA0BHwdndvdQuyskehlaWMnDpCF5h2e9af 5oaDE7otCZT2ssc+PbKIfACAQfUUNKdVRTKP9SaclpL9gC+7EOivh1O5+KJ31ho= =2/tf -----END PGP SIGNATURE----- --------------enigD3A84E05839B3B5BC848BE21--