Re: [Qemu-devel] [Nbd] [PATCH] Strawman proposal for NBD structured replies

[Wouter Verhelst <w@uter.be>]

On Tue, Mar 29, 2016 at 09:39:43PM +0100, Alex Bligh wrote:
> Here's a strawman for the structured reply section. I haven't
> covered negotation.

LGTM, for the most part.

[...]
> +Each chunk consists of the following:
> +
> +S: 32 bits, 0x668e33ef, magic (`NBD_STRUCTURED_REPLY_MAGIC`)
> +S: 32 bits, flags (including type)
> +S: 64 bits, handle
> +S: 32 bits, payload length
> +S: (*length* bytes of payload data)
> +
> +The flags have the following meanings:
> +
> +* bits 0-7: `NBD_CHUNKTYPE`, an 8 bit unsigned integer
> +* bits 8-31: reserved (server MUST set these to zero)

I understand why you do it this way (we don't need 2^16 reply types),
but (in contrast to the flags in the request packet) this makes it
harder to specify flags and command type as separate fields (there is no
24-bit integer on most systems).

As said though, I understand why, and the alternative isn't ideal.

[...]
> +If the server detects an error during an operation which it
> +is serving with a structured reply, it MUST complete
> +the transmission of the current data chunk if transmission
> +has started (by padding the current chunk with data
> +which MUST be zero), after which zero or more other
> +data chunks may be sent, followed by an `NBD_CHUNKTYPE_END`
> +chunk. The server MAY set the offset within `NBD_CHUNKTYPE_END`
> +to the offset of the error; if so, this MUST be within the
> +length requested.

This should probably also be more explicit about what to do if the
server doesn't want to set the offset (set it to zero, presumably)

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12