On 03/31/2016 05:23 AM, Alex Bligh wrote: >> + [option #B2 - final transmission flags are accurate, but >> + intermediate transmission flags can anticipate negotiation; state >> + change can be observed if negotiation does not happen] >> + When responding to the `NBD_OPT_EXPORT_NAME` option request (or >> + the `NBD_OPT_SELECT` request of the experimental `SELECT` >> + extension), the server MUST set this transmission flag to 1 if >> + structured replies have been negotiated, and MUST NOT set this >> + flag otherwise; that way, the client MAY reliably use the final >> + state of this flag as a reliable witness of whether to expect a >> + simple reply or structured reply to the `NBD_CMD_READ` >> + transmission request. When responding to the `NBD_OPT_LIST` >> + option request, the server MAY set this transmission flag, even if >> + structured replies have not yet been negotiated. > > This is an export flag, yes? Save in oldstyle negotiation (which surely > no one cares about as structured replies can't have been negotiated) the > export flags are sent after option haggling, in which case we always > know whether to set this - we set it to 1 if structured replies have > been negotiated, or to 0 otherwise. That's all this needs to say. > > Therefore the difference in text merely comes down to its additional > use in the SELECT extension. That can be covered by a simple section > in the SELECT extension saying "The value of NBD_FLAG_SEND_DF in > the select extension cannot be relied upon by the Client and MUST > be set to zero by the server. This is because at the stage the > SELECT extension is negotiated, structured replies may or may not > have been negotiated". Hmm. If OPT_LIST reports 0, that's okay; we'll send transmission flags again later during OPT_EXPORT_NAME/OPT_SELECT. But if OPT_SELECT reports 0, and then you negotiate structured replies, and then call OPT_GO, you do not get any further transmission flags from the server. I think what I will have to do is state that the client SHOULD complete structured reply negotiation before OPT_SELECT, otherwise it must not rely on the value of the flag (but in the case of userspace-to-kernel handoff, the fact that we reserved a bit in the protocol means that userspace could still reconstruct the correct flag to pass to the kernel based on the result of structured reply negotiation, rather than relying on the state of the bit returned from OPT_SELECT). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature