From patchwork Thu Apr 7 04:12:10 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Blake X-Patchwork-Id: 8768511 Return-Path: X-Original-To: patchwork-qemu-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 5B4809F36E for ; Thu, 7 Apr 2016 04:13:31 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 9D6BB20172 for ; Thu, 7 Apr 2016 04:13:30 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 72E5D20131 for ; Thu, 7 Apr 2016 04:13:29 +0000 (UTC) Received: from localhost ([::1]:47530 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ao1Jv-0007gK-OJ for patchwork-qemu-devel@patchwork.kernel.org; Thu, 07 Apr 2016 00:13:27 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33796) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ao1Jo-0007g7-S8 for qemu-devel@nongnu.org; Thu, 07 Apr 2016 00:13:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ao1Jj-0005gf-SO for qemu-devel@nongnu.org; Thu, 07 Apr 2016 00:13:20 -0400 Received: from resqmta-po-03v.sys.comcast.net ([96.114.154.162]:57031) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ao1Jj-0005gB-NO for qemu-devel@nongnu.org; Thu, 07 Apr 2016 00:13:15 -0400 Received: from resomta-po-10v.sys.comcast.net ([96.114.154.234]) by comcast with SMTP id o1IPaKcNGYPZXo1IkaQEVe; Thu, 07 Apr 2016 04:12:14 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460002334; bh=O4hPz+QClpLvn0hljnmBqpFaUEQXHVg6GE8KyVEAWks=; h=Received:Received:From:To:Subject:Date:Message-Id; b=MJUZmdlUoGQm/h1MBh/42WMVjq2XPdces9drxG63g3wvj5drR8HLPlEa/Jc4ktCXv Ddr+6JQs5XevXtJsxu+QSOFSbRwnEV9n/A9h8qFPmeo5dooWVYc5VMH9uTb0XCfONK 1EJmnlzehdxcdj2jqaQM7WrENKN06maBB7EmofjgvHvup1eJe38djENRHuOnEGXCU3 UXZULWR9nIPkE+vLU7wkvBJsYPitLOREHC88LnZyIo4D1Ds1BKP2MPGqtYMzmeOEZd 7MyPH62cQpskS+Xp8cl8R+4qn0b6xkNUIT7nH9tWPD52ItI3KL3WoX9V42cy6gyXZe NHBgsBNezo1hQ== Received: from red.redhat.com ([24.10.254.122]) by resomta-po-10v.sys.comcast.net with comcast id fGCB1s0062fD5rL01GCEjn; Thu, 07 Apr 2016 04:12:14 +0000 From: Eric Blake To: nbd-general@lists.sourceforge.net Date: Wed, 6 Apr 2016 22:12:10 -0600 Message-Id: <1460002330-20965-1-git-send-email-eblake@redhat.com> X-Mailer: git-send-email 2.5.5 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 96.114.154.162 Cc: qemu-devel@nongnu.org Subject: [Qemu-devel] [PATCH] doc: Revert swap of NBD_REP_SERVER fields in NBD_OPT_GO X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 Reviewed-by: Alex Bligh --- 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