From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58481) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1alLVh-0005PN-0I for qemu-devel@nongnu.org; Wed, 30 Mar 2016 15:10:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1alLVf-0005f1-QA for qemu-devel@nongnu.org; Wed, 30 Mar 2016 15:10:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39589) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1alLVf-0005eO-JK for qemu-devel@nongnu.org; Wed, 30 Mar 2016 15:10:31 -0400 References: <1459291701-13679-1-git-send-email-alex@alex.org.uk> <56FB0D20.2020102@redhat.com> <0793954F-3BF5-4855-A32D-3ACC32F67FCB@alex.org.uk> <20160330073339.GA5964@grep.be> <56FC1E6D.8060104@redhat.com> From: Eric Blake Message-ID: <56FC24A5.1090209@redhat.com> Date: Wed, 30 Mar 2016 13:10:29 -0600 MIME-Version: 1.0 In-Reply-To: <56FC1E6D.8060104@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KTab54rbeikHQXgkj3rVQtgNigwsK3BRS" Subject: [Qemu-devel] NBD_REP_SERVER layout [was: [PATCHv2] Strawman proposal for NBD structured replies] List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wouter Verhelst , Alex Bligh Cc: "nbd-general@lists.sourceforge.net" , "qemu-devel@nongnu.org" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KTab54rbeikHQXgkj3rVQtgNigwsK3BRS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/30/2016 12:43 PM, Eric Blake wrote: > On that tangent, I found SELECT slightly ambiguous (particularly since > I'm also considering a proposal to modify NBD_REP_SERVER to expose > alignment details, so it would have to play nicely with SELECT): >=20 > Based on normative text alone, we would have: >=20 > S: 64 bits, 0x3e889045565a9 > S: 32 bits, NBD_OPT_SELECT (6) > S: 32 bits, NBD_REP_SERVER (2) > S: 32 bits, length > S: 32 bits, name length > S: 'name length' bytes, UTF-8 encoded name (is it NUL-terminated?) > S: 'length - name length' bytes, which is UTF-8 encoded message to > display to human >=20 > This implies that 'name length' <=3D 'length - 4', although we don't > actually state that the server MUST NOT send a name length longer than > that. It might not hurt to also require that length include space for = a > NUL terminator (in both the name, and in the optional human-readable > information field), but only if that matches existing practice (if it > does not, then we should document that the client and server are NOT > dealing with NUL-terminated UTF-8 strings, but relying on length instea= d). >=20 > The SELECT text then refines this: >=20 > S: 64 bits, 0x3e889045565a9 > S: 32 bits, NBD_OPT_SELECT (6) > S: 32 bits, NBD_REP_SERVER (2) > S: 32 bits, length > S: 32 bits, name length > S: 'name length' bytes, UTF-8 encoded name (is it NUL-terminated?) > S: 64 bits, size > S: 16 bits, export flags >=20 > but doesn't mention what happens if 'length' > 'name length + 14'. > Presumably, if the server wants to include the same UTF-8 human > information as before, it would go AFTER the 16 bits for the export > field (in other words, the SELECT extension is carving out fields in th= e > MIDDLE of the payload). Actually, now that I've thought about it, I wonder if it is better to arrange data so that there is _always_ a UTF-8 human-readable string immediately after the name (with 1-byte content of "" as the minimum), so that clients can just blindly print that string, even if binary data appears later in the structure due to other things (such as NBD_OPT_SELECT) specifying the layout of that binary data. But if we go with that approach, then we should probably document that NBD_REP_SERVER sent in reply to NBD_OPT_SELECT must have length >=3D 'name-length + 15'.= Anywhere that we put binary data where a client used to be expecting human-readable data risks an unprepared client printing garbage. >=20 > So, once I know for sure about the handling of NUL bytes, I'll probably= > try my hand at a patch to clarify the wording in both the normative and= > in the SELECT extension. At any rate, I hope that I've brought attention to the issue, and that part of moving SELECT out of experimental and into normative will involve documenting decisions you actually make while implementing things= =2E --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --KTab54rbeikHQXgkj3rVQtgNigwsK3BRS 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/ iQEcBAEBCAAGBQJW/CSlAAoJEKeha0olJ0NqhHcH/jQLISETmOp95V4EohxJVmV1 VJpxMguxU+J7uuorsdeX9z4aS3VORzvgPWUpb/5CLmqk0ynkBAEYvLEYcPQbFBhE NfyZcrsGfJq/9tRPk1WPG5kWipBLwpdxHp4PlAmEaSTbjXN+BF8BKNTOkMn/uvgz Nls/uEjDS7fU4ipKcgqKGfxPhnXABNm6vZdgRN29pvMoWOBp/oih+K/nowDUuOJ8 wkS2njVLfxa8uEtWMJyFpD2A0I/eH9njfaYhknFTzaqnMy5iiFKLqVmRhyjF7try Bo+hYjF+FYnkRau2tV9x7E2u5dwgy3muwU+MwK+kgTw9+2WZ6D+Yik0hll3iCIM= =VnPO -----END PGP SIGNATURE----- --KTab54rbeikHQXgkj3rVQtgNigwsK3BRS--