2010/11/30 Anthony Liguori <anthony@xxxxxxxxxxxxx>: > On 11/29/2010 10:53 AM, Paul Brook wrote: >>>> >>>> Is this a fair summary: any device that supports live migration workw >>>> under Kemari? >>>> >>> >>> It might be fair summary but practically we barely have live migration >>> working w/o Kemari. In addition, last I checked Kemari needs additional >>> hooks and it will be too hard to keep that out of tree until all devices >>> get it. >>> >> >> That's not what I've been hearing earlier in this thread. >> The responses from Yoshi indicate that Stefan's summary is correct. i.e. >> the >> current Kemari implementation may require per-device hooks, but that's a >> bug >> and should be fixed before merging. >> > > It's actually really important that Kemari make use of an intermediate layer > such that the hooks can distinguish between a device access and a recursive > access. > > You could s/bdrv_aio_multiwrite/bdrv_aio_multiwrite_internal/g and then > within kemari, s/bdrv_aio_multiwrite_proxy/bdrv_aio_multiwrite/ but I don't > think that results in a cleaner interface. > > I don't like the _proxy naming and I think it has led to some confusion. I > think having a dev_aio_multiwrite interface is a better naming scheme and > ultimately provides a clearer idea of why a separate interface is needed--to > distinguish between device accesses and internal accesses. Sorry about the naming. But from the discussion so far, adding an intermediate layer and exporting it to some/all approach needs a strong reason. Kemari itself can be implemented w/ or w/o the intermediate layer, and this makes the discussion toward folding the layer into block/net to be appropriate. I think there are two perspectives to decide which way to go: - What is clean interfaces for upper/lower layer? - If we introduce the intermediate layer, is there anyone who may use now or in the future? If not, it may not be worth to add. Yoshi > > BTW, dev_aio_multiwrite should take a DeviceState * and a BlockDriverState. > > Regards, > > Anthony Liguori > >> Paul >> -- >> 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 > -- 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
