Re: [Nbd] [Qemu-devel] [PULL 23/28] nbd: always query export list in fixed new style protocol
- To: Eric Blake <eblake@...696...>
- Cc: "nbd-general@lists.sourceforge.net" <nbd-general@lists.sourceforge.net>, "Daniel P. Berrange" <berrange@...696...>, "Richard W.M. Jones" <rjones@...696...>, "qemu-devel@...530..." <qemu-devel@...530...>, Paolo Bonzini <pbonzini@...696...>
- Subject: Re: [Nbd] [Qemu-devel] [PULL 23/28] nbd: always query export list in fixed new style protocol
- From: Wouter Verhelst <w@...112...>
- Date: Sat, 21 May 2016 23:53:12 +0200
- Message-id: <20160521215312.GA8497@...3...>
- In-reply-to: <573B4BB9.50701@...696...>
- References: <1455640486-6101-1-git-send-email-pbonzini@...696...> <1455640486-6101-24-git-send-email-pbonzini@...696...> <20160517095339.GD28935@...696...> <573B342E.8030208@...696...> <5ED6FB6F-5023-4833-83F9-B24BD379E2CD@...872...> <573B3E3E.60902@...696...> <B514F1F3-F3D8-4F86-942D-E1D12273762F@...872...> <573B4BB9.50701@...696...>
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
Reply to: