From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54335) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SzSSw-0002U1-JI for qemu-devel@nongnu.org; Thu, 09 Aug 2012 09:07:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SzSSq-0001PV-Jy for qemu-devel@nongnu.org; Thu, 09 Aug 2012 09:07:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62445) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SzSSq-0001JX-Be for qemu-devel@nongnu.org; Thu, 09 Aug 2012 09:07:48 -0400 Message-ID: <5023B5B8.8040604@redhat.com> Date: Thu, 09 Aug 2012 07:06:00 -0600 From: Eric Blake MIME-Version: 1.0 References: <1344355108-14786-1-git-send-email-coreyb@linux.vnet.ibm.com> <1344355108-14786-3-git-send-email-coreyb@linux.vnet.ibm.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigDB4D85AAE9DCF17A9973B61D" Subject: Re: [Qemu-devel] [libvirt] [PATCH v7 2/6] qapi: Introduce add-fd, remove-fd, query-fdsets List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: kwolf@redhat.com, aliguori@us.ibm.com, stefanha@linux.vnet.ibm.com, libvir-list@redhat.com, Corey Bryant , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDB4D85AAE9DCF17A9973B61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 08/09/2012 03:04 AM, Stefan Hajnoczi wrote: > On Tue, Aug 7, 2012 at 4:58 PM, Corey Bryant wrote: >> +## >> +# @FdsetFdInfo: >> +# >> +# Information about a file descriptor that belongs to an fd set. >> +# >> +# @fd: The file descriptor value. >> +# >> +# @removed: If true, the remove-fd command has been issued for this f= d. >> +# >> +# Since: 1.2.0 >> +## >> +{ 'type': 'FdsetFdInfo', 'data': {'fd': 'int', 'removed': 'bool'} } >=20 > I'm not sure if the removed field is useful, especially since > remove-fd is idempotent (you can keep querying fds and then marking > them removed again until they finally close). The reason I suggest > minimizing the schema is so that we can change implementation details > later without having to synthesize this state. Pretty much agreed - rather than listing 'removed', omitting the fd by default will match the monitors expectations ("why are you telling me about an fd I told you to remove?"). The only reason I could see for keeping it would be for debug purposes, but that would be debugging of qemu, not the application connected to the monitor, at which point gdb debugging is probably better. >> +{ 'type': 'FdsetInfo', >> + 'data': {'fdset_id': 'int', 'refcount': 'int', 'in_use': 'bool', >> + 'fds': ['FdsetFdInfo']} } >=20 > Why are refcount and in_use exposed? How will applications use them? > This seems like internal state to me. refcount _might_ be useful for knowing whether qemu is actively using the fdset. For example, in the sequence: add-fd nnn drive-add if libvirtd crashes after sending drive-add but before getting a response, then on restart it has to figure out if the drive-add took or failed. A non-zero refcount means it took. But then again, so does a query-block. I like the approach of being minimal until we prove we need it, and can't right now think of anything where having a refcount would tell libvirt anything new that it can't already learn from somewhere else. >=20 > Should add-fd allow the application to associate an opaque string with > the fdset? This could be used to recover after crash. Otherwise the > application needs to store the fdset_id -> filename mapping in a file > on disk and hope it was safely stored before crash. It seems like the > best place to keep this info is with the fdset. Very nice idea! In fact, even nicer than returning a markup of O_RDONLY - if the management app cares about knowing details on an fd, such as whether it is read-only, then an opaque string tied to the fd in the fdset becomes very useful. The string needs to be optional on add-fd. (Libvirt might even use an xml-like string like "", but of course, being an opaq= ue string, qemu doesn't have to care what the string contains.) --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enigDB4D85AAE9DCF17A9973B61D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJQI7W5AAoJEKeha0olJ0NqV2kH/Ax8CKLGLrkIRzKUqQMNZoyx PlFk44Ij1CmIqA7d/lzgqHmv+hNdSbWaUua79XH2bRZr7vlUMRwgeIiHh+4eN9c8 bndBt3Z2TMsmIQgYpALXHqed4aOQwGA1UjQufpNaj0E0U/NmVvz2VPkuJwH9BKWh RXNRypawi+Q1kJAsoJb7Q6D3ROn/ehjWmpJC3WIwCtdQN4tNMV/1NbUQ94DldDr5 ogqGoAFFpDaBJvoeqe9nt1dSPSKq+8GXxfL1lAZGBB76ZgF6KIp0NiSNIHmjvzTp LE5FsxJFP4PptgykziQRkPaY3L9UbD6BSFcVVatt4oQhm9Wd+eR3k2RgE2BcV/Q= =vp4y -----END PGP SIGNATURE----- --------------enigDB4D85AAE9DCF17A9973B61D--