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

Re: [Nbd] [PATCH/RFC] Synchronize the option haggling phase



On 04/21/2016 04:31 AM, Alex Bligh wrote:
> 
> On 20 Apr 2016, at 16:48, Wouter Verhelst <w@...112...> wrote:
> 
>> On Mon, Apr 18, 2016 at 01:49:45PM -0600, Eric Blake wrote:
>>> plus simplifications to NBD_OPT_GO:
>>>
>>> diff --git i/doc/proto.md w/doc/proto.md
>>> index 8ef339c..c85e0aa 100644
>>> --- i/doc/proto.md
>>> +++ w/doc/proto.md
>>> @@ -949,11 +949,7 @@ of the newstyle negotiation.
>>>     with `NBD_REP_ACK`), the client and the server both immediately
>>>     enter the transmission phase. The server MUST NOT send any zero
>>>     padding bytes after the `NBD_REP_ACK` data, whether or not the
>>> -    client negotiated the `NBD_FLAG_C_NO_ZEROES` flag. The server MUST
>>> -    NOT send the final `NBD_REP_ACK` reply until all other pending
>>> -    option replies have been sent by the server, and a client MUST NOT
>>> -    send any further option requests after `NBD_OPT_GO` unless it
>>> -    first receives an error reply.
>>
>> These last two lines still apply; a client sending another option after
>> having sent NBD_OPT_GO is stupid.
> 
> I'm puzzled as to where this bit of patch came from, as it wasn't the one mentioned
> in the thread in the header.

I had two potential followups to your original proposal - one to clean
up some wording on the master branch in other places that were written
to combat out-of-order haggling (not shown here), and then this one on
the extensions-info branch.  Now that your patch is in, I'll resubmit
them as formal patches.

Speaking of the extension branches, are we planning on rebasing them
(where I should be expecting a non-fast-forward pull), or merely doing
merges from master into the extension branches (and if so, how
frequently)?  Right now, they diverge a bit from the master branch,
although I don't think we have any major conflicts to worry about; but
the longer we let them diverge, the harder it may be to eventually merge
the extensions back into master.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: