On 29 Mar 2016, at 23:45, Wouter Verhelst <w...@uter.be> wrote: > Doing that requires performing a lookup to negotiated state (and a code > branch) for every response type that can possibly be structured or > nonstructured, and introduces exactly the two code paths that I think > should be avoided. > > With what I'm suggesting, this will still be required for read requests, > but only while we retain backwards compatibility.
OK, I *think* I've encapsulated all 3 options in the revised version I just sent. From the other email: >> As a third option then: >> >> Each chunk consists of the following: >> >> S: 32 bits, 0x668e33ef, magic (NBD_STRUCTURED_REPLY_MAGIC) >> S: 8 bits: type >> S: 8 bits: reserved (must be zero) >> S: 16 bits, flags >> S: 64 bits, handle >> S: 32 bits, payload length S: (length bytes of payload data) >> >> The flags have the following meanings: >> >> • bits 0-15: reserved (server MUST set these to zero) > > That seems better in that context, yes. The reserved byte could later on > be assigned as extra flags if need be. Or for compatibility with NBD_CMD, it could be 2 16 bit quantities. Missed this on v2. > The reason why I suggested zero is that it doesn't require special-case > code. If an error offset implies that everything beyond that offset is > invalid, then having an offset of zero implies that the whole read is > invalid -- which is correct if the server encountered an error, but > doesn't know or doesn't want to say (for whatever reason) where. I think that's wrong. As reads can be disordered, then if you get a chunk at offset X, then a chunk at offset 0, then an end chunk specifying an error, you (at least in theory) need to disambiguate the two so you know whether the chunk at offset X was OK. That's why I'm using 0xffffffff (now) to say "don't know where the error is". -- Alex Bligh
