On 03/31/2016 05:39 PM, Alex Bligh wrote: > > 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. Ooh, I like it. Seems like NBD_OPT_GO can just return NBD_REP_SERVER (not NBD_REP_ACK), and with the same semantics as NBD_OPT_SELECT, at which point we're set. That will be an easy one to write up, especially since we don't know of anyone that has actually implemented it yet. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature