From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39651) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akyys-0007k3-VV for qemu-devel@nongnu.org; Tue, 29 Mar 2016 15:07:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akyyo-0005Jr-UB for qemu-devel@nongnu.org; Tue, 29 Mar 2016 15:07:10 -0400 Received: from barbershop.grep.be ([89.106.240.122]:39547) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akyyo-0005Jg-ON for qemu-devel@nongnu.org; Tue, 29 Mar 2016 15:07:06 -0400 Date: Tue, 29 Mar 2016 21:06:52 +0200 From: Wouter Verhelst Message-ID: <20160329190652.GD12469@grep.be> References: <1459173555-4890-1-git-send-email-eblake@redhat.com> <1459223796-28474-2-git-send-email-eblake@redhat.com> <20160329175319.GA8628@grep.be> <56FAC823.8070206@redhat.com> <20160329185157.GC12469@grep.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160329185157.GC12469@grep.be> Subject: Re: [Qemu-devel] [Nbd] [PATCH 3/1] doc: Propose Structured Replies extension List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: nbd-general@lists.sourceforge.net, qemu-devel@nongnu.org On Tue, Mar 29, 2016 at 08:51:57PM +0200, Wouter Verhelst wrote: > On Tue, Mar 29, 2016 at 12:23:31PM -0600, Eric Blake wrote: > > Unfortunately, I chose the design of 0 or more structured replies > > followed by a normal reply, so that the normal reply is a reliable > > indicator that the read is complete (whether successful or not); and the > > whole goal of the extension is to avoid sending any data payload on a > > normal reply. I'm not sure how to send the offset in the normal reply > > without violating the premise that a normal reply has no payload. > > Oh. I thought you meant for the concluding message to also be a > structured reply with the length field be zero, but you mean for it to > be a non-structured reply message? If so, you should clarify that a bit > more (this wasn't clear to me)... Also, I'm not convinced that's a very good approach, since it also requires analyzers to have more context than just requiring a single final "empty" structured reply message. -- < 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