From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [uq/master patch 2/5] kvm: add logging count to slots Date: Sun, 25 Apr 2010 16:29:45 +0200 Message-ID: <4BD451D9.4090209@web.de> References: <20100423170410.914857113@amt.cnet> <20100423170645.675040544@amt.cnet> <4BD29F22.8020806@web.de> <4BD4367F.5060307@redhat.com> <4BD44A4D.4060008@web.de> <4BD44F13.3070000@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF924358E7EB6AB5E4C43EFA6" Cc: Marcelo Tosatti , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Avi Kivity Return-path: Received: from fmmailgate03.web.de ([217.72.192.234]:51961 "EHLO fmmailgate03.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751485Ab0DYO3v (ORCPT ); Sun, 25 Apr 2010 10:29:51 -0400 In-Reply-To: <4BD44F13.3070000@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF924358E7EB6AB5E4C43EFA6 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable 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 o= nly >>> one slot-based client (or that multiple clients will keep the refcoun= t >>> 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()/). >>> >>> =20 >> No concerns if >> - there is an existing use case for multiple clients, at least in >> qemu-kvm >> =20 >=20 > 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...". >=20 >> - the logging API is consistently converted, not just extended >> (IOW, migration_log is converted to logging_count) >> =20 >=20 > 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? >=20 >> - someone signs he checked that current use of start/stop in qemu is= >> completely symmetrical (I think to remember this used to be not th= e >> case, but I might be wrong) >> =20 >=20 > I remember this too. Marcelo? >=20 Jan --------------enigF924358E7EB6AB5E4C43EFA6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkvUUdwACgkQitSsb3rl5xR3sgCgyMaoAlkeMGnu3w4BKdYwDy0L clUAn3o35Uw2Le8F5/Kq/cqDLn8Pf51E =398p -----END PGP SIGNATURE----- --------------enigF924358E7EB6AB5E4C43EFA6--