Minor nitpick: On Fri, Nov 27, 2015 at 12:20:50PM +0000, Daniel P. Berrange wrote: [...] > @@ -563,6 +659,14 @@ static int nbd_receive_options(NBDClient *client) > case NBD_OPT_EXPORT_NAME: > return nbd_handle_export_name(client, length); > > + case NBD_OPT_STARTTLS: > + if (client->tlscreds) { > + TRACE("TLS already enabled"); > + } else { > + TRACE("TLS not configured"); > + } > + nbd_send_rep(client->ioc, NBD_REP_ERR_UNSUP, clientflags);
NBD_REP_ERR_UNSUP is supposed to be reserved as the default reply for replies unknown to a server implementation (i.e., it's "this request is not supported by this server"). Trying to negotiate TLS in a TLS channel would be NBD_REP_ERR_INVALID ("invalid request"). Trying to negotiate TLS when no TLS configuration is available server-side would be NBD_REP_ERR_POLICY ("request not allowed by server-side policy"). Keeping to these error codes would allow a client to provide more useful information to a user beyond "haha it fail"; but I suppose there can be arguments for not doing so, too. Beyond this and the default export that I talked about earlier, no comments. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26