On Tue, Aug 11, 2020 at 01:02:40PM -0500, Eric Blake wrote:
>>Should setting the opt flag cause a failure if we connect to
an
>>oldstyle server? (I can see arguments both ways.)
We don't know if the server is oldstyle until after the magic
numbers have been parsed. As coded in this patch, state Negotiating
can only be reached from a newstyle-fixed server (not even a plain
newstyle server will get here, since that must go straight to
NBD_OPT_EXPORT_NAME which has no error detection short of killing
the connection). So our options after the user calls
nbd_set_opt_mode(nbd, true) are:
1. silently proceed to nbd_aio_is_ready; the user never got a chance
to reach Negotiating, and can readily deduce that this was because
the server didn't support negotiation. The lack of negotiation does
not stop the user from using the export.
2. error out at the magic number detection to inform the user that
negotiation mode is not reachable with the given server. But the
user can always create a new nbd handle, and retry again this time
without setting nbd_set_opt_mode.
I coded 1, but 2 also makes sense. I could go either way, if you
have a preference.
2 is horrible for consumers of the API, so 1 is easier to consume. It
may depend on how we expect this to be used. If it's only ever for
listing exports, then because oldstyle servers don't have exports
there's no need to interrupt the connection.
It might be worth a test especially since it's just testing against
“nbdkit -o” and making sure it doesn't do anything bad/stupid.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html