On 04/01/2016 02:57 AM, Wouter Verhelst wrote: > Did a few minor changes, though: > > On Thu, Mar 31, 2016 at 11:29:48PM -0600, Eric Blake wrote: >> -S: 32 bits, 0x67446698, magic (`NBD_REPLY_MAGIC`) >> -S: 32 bits, error >> +S: 32 bits, 0x67446698, magic (`NBD_SIMPLE_REPLY_MAGIC`) > > Added a reference to the old name, for clarity. > > [...] >> +- bit 6, `NBD_FLAG_SEND_DF`; defined by the `STRUCTURED_REPLY` extension; >> + see below. > > This is now bit 7 (we're already halfway through our available flags! time > flies...) Well, if (when?) we get to 15, one possible solution is fairly straightforward: the server advertises a handshake flag, and the client replies with the counterpart flag, and then both sides know to send 64 bits instead of 16 bits for all places that send a transmission flag. It may make documentation of NBD_REP_SERVER (as used by NBD_OPT_GO) a bit trickier, in that the length returned in the option reply is dependent on what handshake flags were negotiated. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature