2010/11/29 Kevin Wolf <kwolf@xxxxxxxxxx>: > Am 28.11.2010 12:55, schrieb Yoshiaki Tamura: >> 2010/11/28 Michael S. Tsirkin <mst@xxxxxxxxxx>: >>> On Thu, Nov 25, 2010 at 03:06:52PM +0900, Yoshiaki Tamura wrote: >>>> Replace bdrv_aio_writev() with bdrv_aio_writev_proxy() to let >>>> event-tap capture events from dma-helpers. >>>> >>>> Signed-off-by: Yoshiaki Tamura <tamura.yoshiaki@xxxxxxxxxxxxx> >>> >>> Same comment as -net here: it's not clear when should >>> a device use bdrv_aio_writev_proxy and when bdrv_aio_writev. >>> If all devices should just use _proxy, let's >>> just make bdrv_aio_writev DTRT instead. >> >> Same as I replied to the net layer question. However, I had >> troubles with inserting event-tap functions into block.c before. >> block.c gets linked with utils like qemu-img, but they don't get >> linked with emulators code which event-tap uses in it. So I want >> to avoid linking block and event-tap for utils, but I guess we >> don't want to use ifdefs for this. I'm wondering how I can solve >> this problem cleanly. >> >> Kevin, do you have suggestions here? > > Michael's stubs (probably in qemu-tool.c) seem to be the right solution. Same here. I noticed kvm-stub to be a good example. > Which requests do you actually want to intercept? I assume you're aware > that for example qcow2 internally calls another bdrv_aio_readv/writev > that accesses the image file. > > So if you only want to have the requests that come directly from > devices, maybe you'll have to restrict it to BlockDriverStates that > belongs to a drive. I think this is the case if it has a non-empty > device name. Yes, exactly. I noticed that a little while ago. Thanks for making it clear. > > Kevin > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
