From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36526) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zzope-0001yx-1H for qemu-devel@nongnu.org; Fri, 20 Nov 2015 11:46:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zzopa-0006Va-OE for qemu-devel@nongnu.org; Fri, 20 Nov 2015 11:46:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41704) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zzopa-0006VS-FV for qemu-devel@nongnu.org; Fri, 20 Nov 2015 11:46:38 -0500 References: <87si401wpf.fsf@blackfin.pond.sub.org> <2083526024.12459505.1448036588653.JavaMail.zimbra@redhat.com> From: Eric Blake Message-ID: <564F4E68.8090903@redhat.com> Date: Fri, 20 Nov 2015 09:46:32 -0700 MIME-Version: 1.0 In-Reply-To: <2083526024.12459505.1448036588653.JavaMail.zimbra@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0lwf4f3VhuoFBgfQ1mBTtoXE2IDkpP8fn" Subject: Re: [Qemu-devel] ivshmem property size should be a size, not a string List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= , Markus Armbruster Cc: marcandre lureau , Claudio Fontana , qemu-devel@nongnu.org, Luiz Capitulino This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0lwf4f3VhuoFBgfQ1mBTtoXE2IDkpP8fn Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/20/2015 09:23 AM, Marc-Andr=C3=A9 Lureau wrote: > Hi >=20 > ----- Original Message ----- >> Everybody's favourite device model has "size" property. It's declared= >> as *string* >> >> DEFINE_PROP_STRING("size", IVShmemState, sizearg), >> >> >> * In QMP, the size must be given as JSON string instead of JSON number= , >> and size suffixes are accepted. Example: "size": "512k" instead of >> "size": 524288. >> >> Right now, this violation of QMP rules is tolerable (barely), becaus= e >> device_add breaks some of these rules already. However, one goal of= >> the current work on QAPI is to support a QMP command to plug devices= >> that doesn't break QMP rules, and then this violation will stand out= =2E >> >> Therefore, I want it fixed now, before ivshmem gets used in anger. Was ivshmem even usable in 2.4? I'd argue that if we are going to change it, changing it for 2.5 is the ideal time. >> >> A straight fix of size isn't fully backwards compatible: suffixes no= >> longer work in QMP, and you need to use an 'M' suffix to get Mebibyt= es >> on command line and HMP. >=20 > I don't know the rules to break properties in qemu, but I would prefer = to avoid it if possible. It's possible to use an alternate to accept both a string and an integer. But in general, QMP _wants_ to use byte-count integers without suffix (the convenience of '512k' is only for the command line and HMP), so letting QMP expose a string of "512k" instead of an integer 524288 feels wrong. >=20 >> If that's unacceptable, we'll have to provide a new, fixed property,= >> and deprecate size. >=20 > Sounds a better alternative to me. I'd rather fix the interface rather than catering to ugliness, particularly since 2.5 already fixes so much else that was ugly about ivshmem. Markus, did you have a patch to propose? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --0lwf4f3VhuoFBgfQ1mBTtoXE2IDkpP8fn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWT05oAAoJEKeha0olJ0NqEwkIAJzlX4n8TqxddfZnLl6g57jh ykD78TqZmlylgVZugn8ruJStnCwc3mObajYE/HcnTsRfM/v6MtmBTbnHm1mN+9Ed PGMW2u5kmKIodDhuHIclMV7NPfd+XAmo9zH4Gms8ZPQ69Oqslcd+M2zxBSwiNhSK BuKSEpSCHuU0LfenAtoFo/NeMxFeSmyY14NV/HIvGJ5BeVWxSCB5PaDmoXGQX21F bI7Vb2Aq/YRBCiu8IKKpJPfkrhWxpli6YrKVFdBC2ELE+nU5f5B8RSiY8RcmGWSb n8bL5tHYA87GNl6DMVteuby7OQqVIHDJaDIeqysrSRcovagA8Kl9YPmxxc2wk8c= =qHno -----END PGP SIGNATURE----- --0lwf4f3VhuoFBgfQ1mBTtoXE2IDkpP8fn--