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