On 1 Apr 2016, at 00:26, Eric Blake <eblake@...696...> wrote: > 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). Or better, simply fix NBD_OPT_GO so that it returns the server flags. It's experimental, nobody (to my knowledge) has implemented it, and it's a clear deficiency that it provides less information back than NBD_OPT_EXPORT_NAME which it was meant to replace. If there is a purpose in marking things as experimental, it should be that they can change when deficiencies are discovered. -- Alex Bligh
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail