From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53041) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b4Eq2-00018W-Hs for qemu-devel@nongnu.org; Sat, 21 May 2016 17:53:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b4Epy-0001GE-Eh for qemu-devel@nongnu.org; Sat, 21 May 2016 17:53:37 -0400 Received: from barbershop.grep.be ([89.106.240.122]:41400) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b4Epy-0001DU-8q for qemu-devel@nongnu.org; Sat, 21 May 2016 17:53:34 -0400 Date: Sat, 21 May 2016 23:53:12 +0200 From: Wouter Verhelst Message-ID: <20160521215312.GA8497@grep.be> References: <1455640486-6101-1-git-send-email-pbonzini@redhat.com> <1455640486-6101-24-git-send-email-pbonzini@redhat.com> <20160517095339.GD28935@redhat.com> <573B342E.8030208@redhat.com> <5ED6FB6F-5023-4833-83F9-B24BD379E2CD@alex.org.uk> <573B3E3E.60902@redhat.com> <573B4BB9.50701@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <573B4BB9.50701@redhat.com> Subject: Re: [Qemu-devel] [Nbd] [PULL 23/28] nbd: always query export list in fixed new style protocol List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Alex Bligh , "nbd-general@lists.sourceforge.net" , Paolo Bonzini , "Daniel P. Berrange" , "Richard W.M. Jones" , "qemu-devel@nongnu.org" On Tue, May 17, 2016 at 10:50:01AM -0600, Eric Blake wrote: > Option 2: An alternative solution would be to allow nbdkit to fail > NBD_OPT_LIST with NBD_REP_ERR_UNSUP, at which point qemu client of 2.6 > should just ignore the failure and proceed on to NBD_OPT_EXPORT_NAME. > It is the fact that it is returning NBD_REP_ACK with 0 names that is > giving qemu grief. I think this makes most sense. If you don't look at export names, you effectively don't support them, and you can't be expected to send a list of "supported" names, because *everything* is supported (or, put a different way, nothing is). I note that nbdkit has been patched to now send the empty name, which is also fine as a way to fix interoperability in this particular case -- but for the general case, I think if we want to define ways for a server to explicitly say that it doesn't support export names, returning ERR_UNSUP to OPT_LIST seems cleaner. (That does mean I'll have to fix nbd-client, since it currently assumes that fixed newstyle implies support for OPT_LIST -- but that should be an easy enough patch) > But to date, I think ALL of the options (except NBD_OPT_EXPORT_NAME) > _are_ optional. In fact, I'm arguing that per Option 2, we WANT > NBD_OPT_LIST to be optional for servers that don't care about names. Sortof. Like I said, nbd-client assumes that servers which support fixed newstyle will also support OPT_LIST -- but that's mostly an artefact of the fact that OPT_LIST was used as a test case for fixed newstyle, and isn't necessarily a good enough reason to make that a required part of the protocol. -- < 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