Re: [Qemu-devel] [PATCH v3] block: Introduce "null" driver

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2191 bytes --]

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: and
>>> the null-co: protocol.  (I suspect we would do the same when finaly
>>> adding gluster to BlockdevOptions: rather than having 'gluster+tcp' and
>>> '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, gluster
>> 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 = null_plain' vs. "null_co" having
'.func = null_co' (ie. each driver having different functions
registered, but in the same slots).

> 
> 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 other
> 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         = null_aio_readv,
+    .bdrv_aio_writev        = null_aio_writev,
+    .bdrv_aio_flush         = null_aio_flush,

while "null_co" has
+    .bdrv_read              = null_co_read,
+    .bdrv_write             = null_co_write,
+    .bdrv_co_flush_to_disk  = 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.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]