[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PATCH] structured-reply: Tweak some protocol requirements



On 10/16/2017 12:43 PM, Vladimir Sementsov-Ogievskiy wrote:
> 16.10.2017 18:25, Eric Blake wrote:
>> Several tweaks noticed while implementing structured reply for qemu:
>> - Document what a server may do if the client tries to negotiate
>> structured replies more than once.
>> - Reformat the paragraph on NBD_CMD_FLAG_DF.
>> - Mention what a client should do if a server sends an unexpected
>> structured reply
>>
>> Signed-off-by: Eric Blake <eblake@redhat.com>
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> 

>> @@ -1303,11 +1305,12 @@ valid may depend on negotiation during the
>> handshake phase.
>>     if `NBD_FLAG_SEND_TRIM` was not set in the transmission flags field.
>>     The server MUST support the use of this flag if it advertises
>>     `NBD_FLAG_SEND_WRITE_ZEROES`.
>> -- bit 2, `NBD_CMD_FLAG_DF`; the "don't fragment" flag, valid during
>> `NBD_CMD_READ`.
>> -   SHOULD be set to 1 if the client requires the server to send at
>> most one
>> -   content chunk in reply.  MUST NOT be set unless the transmission
>> -   flags include `NBD_FLAG_SEND_DF`.  Use of this flag MAY trigger an
>> -   `EOVERFLOW` error chunk, if the request length is too large.
>> +- bit 2, `NBD_CMD_FLAG_DF`; the "don't fragment" flag, valid during
>> +  `NBD_CMD_READ`.  SHOULD be set to 1 if the client requires the
>> +  server to send at most one content chunk in reply.  MUST NOT be set
>> +  unless the transmission flags include `NBD_FLAG_SEND_DF`.  Use of
>> +  this flag MAY trigger an `EOVERFLOW` error chunk, if the request
>> +  length is too large.
> 
> only text width is changed

Not just text width, but leading indentation (your email quoting munged
it, but the patch itself changes from a 3-space indent for hanging lines
to a more typical 2-space indent, matching the indentation of 'bit 1'
documentation).  Since indentation is significant in markdown, I figure
it's better to be consistent, even if I couldn't detect a difference in
the rendered output. (Should I have given this much detail in the commit
message? Maybe)

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: