Re: [Qemu-devel] [PATCH 00/21] Kemari for KVM 0.2

[Yoshiaki Tamura]

2010/11/30 Anthony Liguori <address@hidden>:
> 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 address@hidden
>> 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 address@hidden
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>