From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44062) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLYvZ-0002u3-Ie for qemu-devel@nongnu.org; Tue, 19 Jan 2016 11:14:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLYvY-0003Bg-Ob for qemu-devel@nongnu.org; Tue, 19 Jan 2016 11:14:41 -0500 Sender: Paolo Bonzini References: <1453208963-16834-1-git-send-email-berrange@redhat.com> <1453208963-16834-10-git-send-email-berrange@redhat.com> From: Paolo Bonzini Message-ID: <569E60E8.2040001@redhat.com> Date: Tue, 19 Jan 2016 17:14:32 +0100 MIME-Version: 1.0 In-Reply-To: <1453208963-16834-10-git-send-email-berrange@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 09/13] nbd: pick first exported volume if no export name is requested List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , qemu-devel@nongnu.org Cc: qemu-block@nongnu.org On 19/01/2016 14:09, Daniel P. Berrange wrote: > The NBD client is currently only capable of using the new style > protocol negotiation if an explicit export name is provided. > This is a problem, because TLS support will require use of the > new style protocol in all cases, and we wish to keep the export > name as an optional request for backwards compatibility. > > The trivial way to deal with this is to use the NBD protocol > option for listing exports and then pick the first returned > export as the one to use. This makes the client "do the right > thing" in the normal case where the qemu-nbd server only > exports a single volume. > > Furthermore, in order to get proper error reporting of unknown > options with fixed new style protocol, we must not send the > NBD_OPT_EXPORT_NAME as the first thing. Thus, even if an export > name is provided we still send NBD_OPT_LIST to enumerate server > exports. This also gives us clearer error reporting in the case > that the requested export name does not exist. If NBD_OPT_LIST > is not supported, we still fallback to using the specified > export name, so as not to break compatibility with old QEMU > NBD server impls that predated NBD_OPT_LIST > > Signed-off-by: Daniel P. Berrange As a first reaction, I would really avoid magic unless the server provides a single exports. But even in that case, I would prefer to have some synchronization between the server and client command-line. Is an empty NBD_OPT_EXPORT_NAME valid? What about using new-style negotiation with empty NBD_OPT_EXPORT_NAME if TLS is requested? Paolo