Re: [uq/master patch 2/5] kvm: add logging count to slots

Avi Kivity
2010-04-25T14:41:04Z

On 04/25/2010 05:29 PM, Jan Kiszka wrote:
>
>> There isn't. But I don't like hidden breakage.
>>
> It's (so far) an unproblematic API property we can document. I don't
> like changing APIs just for "there might be the case that...".
>

I guess it's one of those agree to disagree things. I dislike known
broken APIs even if their none of their users are affected.

>>> - the logging API is consistently converted, not just extended
>>> (IOW, migration_log is converted to logging_count)
>>>
>>>
>> migration_log needs to remain global, since we want hotplug memory to
>> autostart logging.
>>
> Can't follow yet, what will be the usage pattern of
> kvm_set_migration_log? Or would the hotplug code require a separate
> interface? Is it already the multi-client use case I'm looking for?
>

kvm_set_migration_log() means, start logging now for all current and
future memory, until disabled.

It could be implemented in terms of kvm_log_start() (which would provide
a multi-client use case), but it isn't now.

I guess it is a logical example of how two clients can exist, even
though they don't step on each others toes in practice since their
enable flags are kept separate by the implementation.

--
error compiling committee.c: too many arguments to function