|
From: | Avi Kivity |
Subject: | [Qemu-devel] Re: [uq/master patch 2/5] kvm: add logging count to slots |
Date: | Sun, 25 Apr 2010 17:41:00 +0300 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |