Avi Kivity wrote: > 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 API is not broken. I intentionally designed it for the single user as I saw no need for more. If I oversaw something, I would really like to learn about these cases. > >>>> - 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. Hmm, you mean plugging memory during ongoing migration is valid and can be handled? I'm a bit skeptical. What makes this different from, say, PCI hotplugging which should be a no-go during migration as well? > > 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. > Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
