From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41527) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XN84y-0004DA-71 for qemu-devel@nongnu.org; Thu, 28 Aug 2014 18:22:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XN84t-0000XJ-37 for qemu-devel@nongnu.org; Thu, 28 Aug 2014 18:22:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:16345) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XN84s-0000XC-RL for qemu-devel@nongnu.org; Thu, 28 Aug 2014 18:21:59 -0400 Message-ID: <53FFAB82.7060801@redhat.com> Date: Thu, 28 Aug 2014 16:21:54 -0600 From: Eric Blake MIME-Version: 1.0 References: <1409205191-11406-1-git-send-email-famz@redhat.com> <20140828152224.GA4970@irqsave.net> <53FF5040.1020608@redhat.com> <53FF8621.3040201@redhat.com> <53FFAA1D.8020505@redhat.com> In-Reply-To: <53FFAA1D.8020505@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FHs9fcSTXDskKgOmfh2JIVD2LOndnv5XP" Subject: Re: [Qemu-devel] [PATCH v3] block: Introduce "null" driver List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , =?UTF-8?B?QmVub8OudCBDYW5ldA==?= , Fam Zheng Cc: Kevin Wolf , qemu-devel@nongnu.org, Stefan Hajnoczi , armbru@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FHs9fcSTXDskKgOmfh2JIVD2LOndnv5XP Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 08/28/2014 04:15 PM, Eric Blake wrote: > On 08/28/2014 01:42 PM, Paolo Bonzini wrote: >> Il 28/08/2014 17:52, Eric Blake ha scritto: >>> have a '*coroutine':'bool' flag here that chooses between the null: a= nd >>> the null-co: protocol. (I suspect we would do the same when finaly >>> adding gluster to BlockdevOptions: rather than having 'gluster+tcp' a= nd >>> 'gluster+udp', it would be a single 'gluster' element that can then >>> select transport of tcp vs. udp as an option). >> >> I'm not sure it's possible in the case of null, since the two >> BlockDriver structs have different function pointers. Instead, gluste= r >> has the same function pointers and just multiple names to trigger the >> parsing of all the URI schemes. Answering myself: I read this paragraph without reading the code, and thought you were talking about "null" having '.func =3D null_plain' vs. "null_co" having '.func =3D null_co' (ie. each driver having different functions registered, but in the same slots). >=20 > But why can't you write a single driver, where each function in the > driver then bases a decision between one of the two original functions > based on the configuration? Is it a case where the set of callback > functions differs with one driver having a NULL callback where the othe= r > does not, and where the presence or absence of the NULL callback > actually matters to the point of requiring two drivers? But now that I read the patch, I see my answer is yes, it DOES matter where the NULL pointers are. "null" has + .bdrv_aio_readv =3D null_aio_readv, + .bdrv_aio_writev =3D null_aio_writev, + .bdrv_aio_flush =3D null_aio_flush, while "null_co" has + .bdrv_read =3D null_co_read, + .bdrv_write =3D null_co_write, + .bdrv_co_flush_to_disk =3D null_co_flush, and the block driver code under test behaves differently depending on which of those callbacks is NULL, where we want to test both behaviors. So it sounds like we really do want two separate QMP driver additions. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --FHs9fcSTXDskKgOmfh2JIVD2LOndnv5XP 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 iQEcBAEBCAAGBQJT/6uCAAoJEKeha0olJ0Nqv98H/2L4f4wMcYIoimRWI3Arem0k EUHg08FChoqPBiiy42rI7suSU/xMPI/hfsbqwFYiIYGlbvAU05Ty5F45AQWf6Qo3 +hnjIADbmtxzK6CkwTrBPijz+bOyl/Er0e8G+liVU2FM2IQ+WlBsFsrwOyutA++o ARf9LwIltKjnlh+hMbxzXMOCHDO8QNFMCVAVYbRSFU9t0R75yc4ozs3UXU6E/9/h 7r4cltNcWzugFtsSiHxFbflT+1JXRWD4NTkUfjtEL3SL3RWuEh91pydGkZth9i5G nlu/wqAkeTyol2JI31tKYL5nkOU1l6Df7qI+0ddEa/cCMlDAQQ51VZoibQ8gqto= =CL/f -----END PGP SIGNATURE----- --FHs9fcSTXDskKgOmfh2JIVD2LOndnv5XP--