Re: [Nbd] NBD_OPT_GO

[Wouter Verhelst <w@...112...>]

On Tue, Apr 05, 2016 at 01:37:26PM +0100, Alex Bligh wrote:
> proto.md is unclear on what export is selected when you use NBD_OPT_GO. I take it
> that the selected export is the one previously selected using NBD_OPT_SELECT.
> If that's the case, it should say that, and it should also say that
> NBD_OPT_GO MUST NOT be used until NBD_OPT_SELECT has been used.
> 
> But this got me thinking. Given the option has a length (which by default would
> be zero), why not allow NBD_OPT_GO (optionally) to carry an export name itself?
> Then it could be used instead of NBD_OPT_EXPORT_NAME completely. We could
> (eventually) deprecate NBD_OPT_EXPORT_NAME. IE if no name is specified, use
> the one from the last NBD_OPT_SELECT, but if one was specified, use that.

Mm. We could also drop NBD_OPT_SELECT completely.

The reason I added SELECT/GO was because EXPORT_NAME has no way for the
server to report error (other than to close the connection). The spec
for GO explicitly states that the server must reply with REP_ACK before
we move on to the transmission phase, so it does not have that problem.

In that light, SELECT is somewhat superfluous. That is, it could be
useful to have a SELECT-like option (so a client can query information
from the server without communicating intent to move on to the
transmission phase), but it might be best to rename NBD_OPT_SELECT to
NBD_OPT_INFO and drop its side effects. Then, a client who wishes to
move on to transmission without using the broken EXPORT_NAME can select
NBD_OPT_GO with (or without) a name, and *if* the server sends ACK,
we're in transmission.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12