|
From: | Ori Mamluk |
Subject: | Re: [Qemu-devel] BlockDriverState stack and BlockListeners |
Date: | Tue, 21 Feb 2012 12:20:49 +0200 |
User-agent: | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 |
On 21/02/2012 11:49, Kevin Wolf wrote:
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).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.
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
[Prev in Thread] | Current Thread | [Next in Thread] |