Re: [Qemu-devel] BlockDriverState stack and BlockListeners

[Ori Mamluk <omamluk@zerto.com>]

On 21/02/2012 11:49, Kevin Wolf wrote:
> Am 21.02.2012 10:15, schrieb Paolo Bonzini:
>>> So maybe we just need to extend the current BlockDriverState stack to
>>> distinguish "normal" and "always on top" BlockDrivers, where the latter
>>> would roughly correspond to BlockListeners?
>> I would prefer having separate objects.  Even if you do not count fields
>> related to throttling or copy-on-read or other tasks in the list above,
>> there are many fields in BDS that do not really apply to BlockListeners.
>>   Backing files, device ops, encryption, even size.  Having extra methods
>> is not a big problem, but unwanted data items smell...
> Most other block drivers use only little of them. We can try to clean up
> some of them (and making the separation described above would probably
> help with it), but BlockListeners aren't really different here from
> existing drivers.
My impression as an outside observer was similar - it appears as though 
the block driver object contains stuff that belongs to the specific 
driver (e.g. bitmap).

An additional capability that I need in the replication filter is for 
the driver to initiate a new IO. It means that if we have a stack of 
drivers guest->bdrv1->bdrv2->bdrv3->image, then bdrv2 should be able to 
invoke a read - which will be processed only by deeper parts of the 
stack - i.e. bdrv3.
Makes sense?

For question of upper/lower drivers, I tend to think that there are two 
kinds - those who need the original guest IO transactions and those who 
transform them. Maybe two separate drivers stack (upper and lower) are 
enough to implement this difference.
> Kevin