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
--
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
