From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39195) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIe70-0003pT-IE for qemu-devel@nongnu.org; Mon, 11 Jan 2016 10:10:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aIe6w-0007OV-JE for qemu-devel@nongnu.org; Mon, 11 Jan 2016 10:10:26 -0500 Date: Mon, 11 Jan 2016 16:10:12 +0100 From: Kevin Wolf Message-ID: <20160111151012.GC9454@noname.redhat.com> References: <87vb7vc2yt.fsf@blackfin.pond.sub.org> <20151223083343.GB8461@stefanha-x1.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline In-Reply-To: <20151223083343.GB8461@stefanha-x1.localdomain> Subject: Re: [Qemu-devel] Minutes from the "Stuttgart block Gipfele" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Fam Zheng , qemu-block@nongnu.org, qemu-devel@nongnu.org, Jeff Cody , Markus Armbruster , Max Reitz , Alberto Garcia , John Snow --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 23.12.2015 um 09:33 hat Stefan Hajnoczi geschrieben: > On Fri, Dec 18, 2015 at 02:15:38PM +0100, Markus Armbruster wrote: > > What should happen when the user asks for a mutation at a place where we > > have implicit filter(s)? >=20 > Please suspend your disbelief for a second: >=20 > In principle it's simplest not having implicit filters. The client > needs to set up throttling nodes or the backup filter explicitly. >=20 > Okay, now it's time to tear this apart: >=20 > For backwards compatibility it's necessary to support throttling, > copy-on-read, backup notifier, etc. It may be possible to tag implicit > filter nodes so that mutation operations that wouldn't be possible today > are rejected. The client must use the explicit syntax to do mutations > on implicit filters. This is easier said than done, I'm not sure it can > be implemented cleanly. Yes, backwards compatibility is what complicates things a bit. > Another problem is that the backup block job and other operations that > require a single command today could require sequences of low-level > setup commands to create filter nodes. The QMP client would need to > first create a write notifier filter and then start the backup block job > with the write notifier node name. It's clumsy. I don't think splitting it up into several low-level commands is necessary. We don't expect the user to set any options for the filter (and if we did, they would probably have to match the same options for the block job), so we can keep the BDS creation as a part of starting the block job. The important part is that the management tool knows that a filter is going to be inserted and how to address it. In order to achieve that, we could simply add a 'filter-node-name' option to the QMP command starting the job. Kevin --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJWk8XUAAoJEH8JsnLIjy/WpdQP/1KdyZ7lQtOQVle5dHiRPw0I MNkTxtWXXV++8kHR6t3q1MZK82WNsMMTISI4upZyjxqWL4H5Q3fnZfYSWuMjxJB1 Ly8Opr2uC9dokdtf1f/xxAnM33iny5OPPlu+kbArTa16NxxE9+UFN/AYtY9ngiEJ Vs1QKESpvm6mMgAJMn4VKj007PZKXYckGXugC09k+vfMTtGrjWVB1Uzae8nO12Gz hWYPESaQ0VO6vAhnz7eElq15k3peXAzxtcW9YSsuO5xTYDdaFArrllly7NCDEBHf 8zexiPpoQD8POSRgS6Ce+jpAUUpzBeW8wokQaMv3lJZNGobNOFUDAdx2m3OKtdrJ kzu64ekiDMFiI9T4JKtdeCX58lyWDu9zwwyk9dYP7l2Yef1rCNyniGefdvNIaCqE GVlQKMFcGds0XR9z1q8wW9knH4NrJhdE7Fg5qVAAJBqqN62kLwpX7oipYUbJA/lU M9o4HLhVz4Q2PSnrdunELj2ID1E00btUW1hiMUpCjnz1CWqRO/d46u1CumpZzrIx EKdBMXrkh0l0p4pgg/d1PjmmMXCm888r1CYbJMwLgmO2Qv6HgpBb5BBf9lzZAiqi N3/IKVESEgiYbBrPS9FSHWmK9rz6bBGIn3ECd5b66EHSnSsZ5jC5XHWNWWoWdbrS xaKSc623aJpeLFv0zUx+ =kTyl -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn--