From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34171) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anDWk-0002L2-Kh for qemu-devel@nongnu.org; Mon, 04 Apr 2016 19:03:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1anDWh-0002Ll-Dp for qemu-devel@nongnu.org; Mon, 04 Apr 2016 19:03:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33168) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anDWh-0002Le-6W for qemu-devel@nongnu.org; Mon, 04 Apr 2016 19:03:19 -0400 References: <1459787950-15286-1-git-send-email-eblake@redhat.com> <20160404224039.GB32049@grep.be> From: Eric Blake Message-ID: <5702F2B5.8060206@redhat.com> Date: Mon, 4 Apr 2016 17:03:17 -0600 MIME-Version: 1.0 In-Reply-To: <20160404224039.GB32049@grep.be> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="j3nS0IcEJAco80IGAFJmkRE4VcC09T05x" Subject: Re: [Qemu-devel] [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wouter Verhelst Cc: nbd-general@lists.sourceforge.net, Kevin Wolf , qemu-devel@nongnu.org, Pavel Borzenkov , Stefan Hajnoczi , "Denis V. Lunev" , Paolo Bonzini This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --j3nS0IcEJAco80IGAFJmkRE4VcC09T05x Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/04/2016 04:40 PM, Wouter Verhelst wrote: > Hi, >=20 > Need to look into this in some detail, for which I don't have the time > (or the non-tiredness ;-) right now, but these two caught my eye: >=20 >> + The payload is structured as a list of one or more descriptors, >> + each with this layout: >> + >> + * 32 bits, length (unsigned, MUST NOT be zero) >> + * 32 bits, status flags >> + >> + The definition of the status flags is determined based on the >> + flags present in the original request. >=20 > Might be a good idea to specify what a client can do with flags it > doesn't know about; ignore them, probably? Sounds correct - so a server can subdivide into more descriptors with additional status bits, and clients just have to ignore those extra bits and coalesce things itself when dealing with the bits it cares about. > =20 > [...] >> +The extension adds the following new command flag: >> + >> +- `NBD_CMD_FLAG_STATUS_DIRTY`; valid during `NBD_CMD_BLOCK_STATUS`. >> + SHOULD be set to 1 if the client wants to request dirtiness status >> + rather than provisioning status. >=20 > Why only one flag here? I could imagine a client might want to query fo= r > both states at the same time. Obviously that means a client needs to > query for *at least* one of the statuses, otherwise the server should > reply with EINVAL. >=20 > Though I'm undecided on whether a bit being set to 0 should mean "give > me that information" or whether 1 should. Hmm. Based on that reading, maybe we want TWO flags: NBD_CMD_FLAG_STATUS_ALLOCATED NBD_CMD_FLAG_STATUS_DIRTY and require that the client MUST set at least one flag (setting no flags at all is boring), but similarly allow that the server MAY reject attempts to set multiple flags with EINVAL (if there is no efficient way to provide the information for all flags on a single pass), in which case clients have to fall back to querying one flag at a time. But while Alex and Denis were arguing that no one would ever query both things at once (and therefore, it might be better to make NBD_STATUS_HOLE and NBD_STATUS_CLEAN both be bit 0), your approach of having two separate request flags and allowing both at once would mean we do need to keep the status information separate (NBD_STATUS_HOLE is bit 0, NBD_STATUS_CLEAN is bit 2). I also see that I failed to reserve a bit for NBD_CMD_FLAG_STATUS_DIRTY. Looks like there will still be some more conversation and at least a v3 needed, but I'll wait a couple days for that to happen so that more reviewers can chime in, without being too tired during the review process= =2E --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --j3nS0IcEJAco80IGAFJmkRE4VcC09T05x 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJXAvK1AAoJEKeha0olJ0NqqLcH/jcclyB90SskgwuJ264ONY+q y5pL7zeGYPQZmXG2Dp7SzMEsG8iklpFV4jo+TV1S16nx9jbGnjqsgGwU7Llz7f5J 06NkxojSL/geyAKgwLOZYLR7ak26RMG87zuUZ8CRIMeVwDcS/3aIh3UlPxAxkAVV qU8g1jQIqm05f65VzKLJymmYuMlNW/UEGxDE2btn6ThKLmUt0qZpJZemnfWGtjrm OLofHIDO1EORPZrHH2IVoa+cCBbxQh7uLYk+3QLn62UD+Ln+9gvZBU2oMLY6+dMM Bx/YUoQP1gxDR1rY+UJOUSjkOY0OB2nQnTvVamfi+yrIvO/vGz1QMqXhsz0flgI= =8vgR -----END PGP SIGNATURE----- --j3nS0IcEJAco80IGAFJmkRE4VcC09T05x--