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): > > Based on normative text alone, we would have: > > 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 > > This implies that 'name length' <= '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 instead). > > The SELECT text then refines this: > > 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 > > 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 the > 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 >= '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. > > 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. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature