Avi Kivity wrote: > On 04/25/2010 04:57 PM, Jan Kiszka wrote: >> >>> It's still a good idea. The current API assumes that there will be only >>> one slot-based client (or that multiple clients will keep the refcount >>> themselves). >>> >>> After the bytemap -> multiple bitmaps conversion this can be >>> extended to >>> each client getting its own bitmap (and therefore, s/refcount/list of >>> bitmaps/ and s/!refcount/list_empty()/). >>> >>> >> No concerns if >> - there is an existing use case for multiple clients, at least in >> qemu-kvm >> > > 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...". > >> - 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? > >> - someone signs he checked that current use of start/stop in qemu is >> completely symmetrical (I think to remember this used to be not the >> case, but I might be wrong) >> > > I remember this too. Marcelo? > Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
