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