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

[Avi Kivity <avi@redhat.com>]

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