doc: Revert swap of NBD_REP_SERVER fields in NBD_OPT_GO

Commit 730c5830 included a reordering of the fields of
NBD_REP_SERVER, under the guise of putting the variable-sized
data last.  However, this makes life harder for sharing
code - the regular NBD_REP_SERVER used by NBD_OPT_LIST
already has _two_ variable-sized fields: name, and an optional
string of additional information, and the wording of the
surrounding text implied that NBD_OPT_GO was just re-purposing
the tail end as binary data instead of a string, not
reorganizing all the fields.

Furthermore, sticking the same fields last in both NBD_OPT_GO
and NBD_OPT_EXPORT_NAME means that any other future handshake
extension that sends a few more bytes of data behind the
transmission flags can do so in both places without reordering
the first half of NBD_REP_SERVER (such an extension is already
envisioned, where the client and server agree to have the server
advertise minimum, preferred, and maximum block sizes).

Signed-off-by: Eric Blake <eblake@redhat.com>
---

I'm trying to implement NBD_OPT_GO in qemu, and found the original
order easier to support than the swapped order.

 doc/proto.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

On 7 Apr 2016, at 05:12, Eric Blake <eblake@redhat.com> wrote:

> Commit 730c5830 included a reordering of the fields of
> NBD_REP_SERVER, under the guise of putting the variable-sized
> data last.  However, this makes life harder for sharing
> code - the regular NBD_REP_SERVER used by NBD_OPT_LIST
> already has _two_ variable-sized fields: name, and an optional
> string of additional information, and the wording of the
> surrounding text implied that NBD_OPT_GO was just re-purposing
> the tail end as binary data instead of a string, not
> reorganizing all the fields.
> 
> Furthermore, sticking the same fields last in both NBD_OPT_GO
> and NBD_OPT_EXPORT_NAME means that any other future handshake
> extension that sends a few more bytes of data behind the
> transmission flags can do so in both places without reordering
> the first half of NBD_REP_SERVER (such an extension is already
> envisioned, where the client and server agree to have the server
> advertise minimum, preferred, and maximum block sizes).
> 
> Signed-off-by: Eric Blake <eblake@redhat.com>

Reviewed-by: Alex Bligh <alex@alex.org.uk>

Thanks for this. I was going to clear this up myself today
having introduced the issue.

Alex

> ---
> 
> I'm trying to implement NBD_OPT_GO in qemu, and found the original
> order easier to support than the swapped order.
> 
> doc/proto.md | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/doc/proto.md b/doc/proto.md
> index 7b36be4..0775360 100644
> --- a/doc/proto.md
> +++ b/doc/proto.md
> @@ -744,13 +744,13 @@ Therefore these commands share common documentation.
>     in place of the default UTF-8 free-form string). The option reply length
>     MUST be *length of name* + 14, and the option data has the following layout:
> 
> -    - 64 bits, size of the export in bytes (unsigned)
> -    - 16 bits, transmission flags.
>     - 32 bits, length of name (unsigned)
>     - Name of the export. This name MAY be different from the one
>       given in the `NBD_OPT_INFO` or `NBD_OPT_GO` option in case the
>       server has multiple alternate names for a single export, or a
>       default export was specified.
> +    - 64 bits, size of the export in bytes (unsigned)
> +    - 16 bits, transmission flags.
> 
>     The server MUST NOT fail an NBD_OPT_GO sent with the same parameters
>     as a previous NBD_OPT_INFO which returned successfully (i.e. with
> -- 
> 2.5.5
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Nbd-general mailing list
> Nbd-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nbd-general
>