On 1 Apr 2016, at 00:26, Eric Blake <[email protected]> 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

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
_______________________________________________
Nbd-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nbd-general

Reply via email to