From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51143) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXAYD-0006UE-Np for qemu-devel@nongnu.org; Wed, 02 Sep 2015 12:06:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZXAY9-0005Al-L5 for qemu-devel@nongnu.org; Wed, 02 Sep 2015 12:06:17 -0400 References: <1441183880-26993-1-git-send-email-wency@cn.fujitsu.com> <1441183880-26993-4-git-send-email-wency@cn.fujitsu.com> From: Eric Blake Message-ID: <55E71E6A.1000001@redhat.com> Date: Wed, 2 Sep 2015 10:06:02 -0600 MIME-Version: 1.0 In-Reply-To: <1441183880-26993-4-git-send-email-wency@cn.fujitsu.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fhkWd6MMHPAq1WaKcEaBPtEvqBuLpkcoh" Subject: Re: [Qemu-devel] [PATCH 03/16] allow writing to the backing file List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wen Congyang , qemu devel , Fam Zheng , Max Reitz , Paolo Bonzini , Stefan Hajnoczi Cc: Kevin Wolf , zhanghailiang , qemu block , Jiang Yunhong , Dong Eddie , "Dr. David Alan Gilbert" , "Michael R. Hines" , Gonglei , Yang Hongyang This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fhkWd6MMHPAq1WaKcEaBPtEvqBuLpkcoh Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 09/02/2015 02:51 AM, Wen Congyang wrote: > Signed-off-by: Wen Congyang > Signed-off-by: zhanghailiang > Signed-off-by: Gonglei Not much description in the commit message. I really want an explanation of why this patch is necessary. After all, with 'block-commit', we were able to turn on read-write mode of backing files on an as-needed basis, without having to expose that to the end user. Giving the end user a knob that they must tune feels a bit awkward, and probably means we don't have the design right. > --- > block.c | 41 ++++++++++++++++++++++++++++++++++++++++- > qapi/block-core.json | 7 ++++++- > 2 files changed, 46 insertions(+), 2 deletions(-) >=20 > +#define ALLOW_WRITE_BACKING_FILE "allow-write-backing-file" > +static QemuOptsList backing_file_opts =3D { > + .name =3D "backing_file", > + .head =3D QTAILQ_HEAD_INITIALIZER(backing_file_opts.head), > + .desc =3D { > + { > + .name =3D ALLOW_WRITE_BACKING_FILE, > + .type =3D QEMU_OPT_BOOL, > + .help =3D "allow write to backing file", If you do add more justification for why this patch is necessary, then, s/write/writes/ > +++ b/qapi/block-core.json > @@ -1408,6 +1408,10 @@ > # @detect-zeroes: #optional detect and optimize zero writes (Since 2.1= ) > # (default: off) > # > +# @allow-write-backing-file: #optional whether the backing file is ope= ned in > +# read-write mode. It is only for backing f= ile > +# (Since 2.5 default: false) > +# The name feels a bit long. It sounds like it is an error to pass allow-write-backing-file for a top-level BDS (that is, the BDS associated with a BB). Meanwhile, the default for any backing chain BDS is to open it read-only, regardless of the 'read-only' setting of the parent. But can we just allow 'read-only':false on a backing BDS to mean that the BDS starts life as read-write, without having to add a new parameter? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --fhkWd6MMHPAq1WaKcEaBPtEvqBuLpkcoh 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/ iQEcBAEBCAAGBQJV5x5qAAoJEKeha0olJ0NqLFYH/1ndM8sVrCCYsM9BMeXEgqcS JjVSnUtA9y7j0f5wdDV3u6VQX94U8AGqZRcHE9EVHmtuB1ok0BJ2pApZFXL3VmCy QUdwjMCsGTHaGwwYiz/21qK3n6PLVMyiLXnr9H/ASuLwVtSsS9nS+rW6fYlI+tGz MX1k8TguE4T0MyBoOoxuzGlDUlasgySZX3NpUU/TaMY2gjoeeIuWwpQXWUPHXzS1 rLf9qYaMkqF3dl4baGUgmNErj3VQ6xnuBdMQVxqTmXegaW/z+/5XI5TcsmSda49I JBc16Ft3pTg+kb9RfwDelSeLcI9+ZeIvObhW0jr25W4GEVb544m6RNCZp4nCIq8= =G9Bc -----END PGP SIGNATURE----- --fhkWd6MMHPAq1WaKcEaBPtEvqBuLpkcoh--