Am 23.11.2012 10:31, schrieb Dietmar Maurer: >>>>> Filters would be implemented as BlockDrivers, i.e. you could >>>>> implement >>>>> .bdrv_co_write() in a filter to intercept all writes to an image. >>>> >>>> I am quite unsure if that make things easier. >>> >>> At least it would make for a much cleaner design compared to putting >>> code for every feature you can think of into bdrv_co_do_readv/writev(). >> >> So if you want to add a filter, you simply modify bs->drv to point to the >> filter? > > Seems the BlockDriver struct does not contain any 'state' (I guess that is by > design), > so where do you store filter related dynamic data?
You wouldn't change bs->drv of the block device, you still need that one after having processed the data in the filter. Instead, you'd have some BlockDriverState *first_filter in bs to which requests are forwarded. first_filter->file would point to either the next filter or if there are no more filters to the real BlockDriverState. Which raises the question of how to distinguish whether it's a new request to bs that must go through the filters or whether it actually comes from the last filter in the chain. As you can see, we don't have a well thought out plan yet, just rough ideas (otherwise it would probably be implemented already). Kevin
