From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42195) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1al0i0-0003l8-7d for qemu-devel@nongnu.org; Tue, 29 Mar 2016 16:57:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1al0hw-0000M6-QH for qemu-devel@nongnu.org; Tue, 29 Mar 2016 16:57:52 -0400 Received: from barbershop.grep.be ([89.106.240.122]:40935) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1al0hw-0000Ly-KU for qemu-devel@nongnu.org; Tue, 29 Mar 2016 16:57:48 -0400 Date: Tue, 29 Mar 2016 22:57:35 +0200 From: Wouter Verhelst Message-ID: <20160329205735.GA19767@grep.be> References: <1459283983-11890-1-git-send-email-alex@alex.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1459283983-11890-1-git-send-email-alex@alex.org.uk> Subject: Re: [Qemu-devel] [Nbd] [PATCH] Strawman proposal for NBD structured replies List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Bligh Cc: "nbd-general@lists.sourceforge.net" , "qemu-devel@nongnu.org" On Tue, Mar 29, 2016 at 09:39:43PM +0100, Alex Bligh wrote: > Here's a strawman for the structured reply section. I haven't > covered negotation. LGTM, for the most part. [...] > +Each chunk consists of the following: > + > +S: 32 bits, 0x668e33ef, magic (`NBD_STRUCTURED_REPLY_MAGIC`) > +S: 32 bits, flags (including type) > +S: 64 bits, handle > +S: 32 bits, payload length > +S: (*length* bytes of payload data) > + > +The flags have the following meanings: > + > +* bits 0-7: `NBD_CHUNKTYPE`, an 8 bit unsigned integer > +* bits 8-31: reserved (server MUST set these to zero) I understand why you do it this way (we don't need 2^16 reply types), but (in contrast to the flags in the request packet) this makes it harder to specify flags and command type as separate fields (there is no 24-bit integer on most systems). As said though, I understand why, and the alternative isn't ideal. [...] > +If the server detects an error during an operation which it > +is serving with a structured reply, it MUST complete > +the transmission of the current data chunk if transmission > +has started (by padding the current chunk with data > +which MUST be zero), after which zero or more other > +data chunks may be sent, followed by an `NBD_CHUNKTYPE_END` > +chunk. The server MAY set the offset within `NBD_CHUNKTYPE_END` > +to the offset of the error; if so, this MUST be within the > +length requested. This should probably also be more explicit about what to do if the server doesn't want to set the offset (set it to zero, presumably) -- < 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