On 04/26/2016 01:36 PM, Alex Bligh wrote: > Allow a client to requests specific bits of information using > NBD_OPT_INFO and thereby signal to the server that it supports them. > This makes it easier for the server to know whether the information > it is providing will be used / respected. > > Now a server can determine whether a client supports block sizes by > the fact it uses NBD_OPT_INFO or NBD_OPT_GO with an NBD_INFO_BLOCK_SIZE, > request as these are part of the same extension, so there is no > need for NBD_OPT_BLOCK_SIZE. > > Signed-off-by: Alex Bligh <alex@...872...> > --- > doc/proto.md | 103 +++++++++++++++++++++++++++++++---------------------------- > 1 file changed, 54 insertions(+), 49 deletions(-) > > @@ -883,8 +897,24 @@ of the newstyle negotiation. > > Data (both commands): > > - - String: name of the export (as with `NBD_OPT_EXPORT_NAME`, the length > - comes from the option header). > + - 16 bits, number of information requests > + - 16 bits x n - list of `NBD_INFO` information requests > + - 32 bits, length of name (unsigned); MUST be no larger than the > + option data length - 6 Could be 16 bits, no larger than 'length - 4', since the maximum name is 4096 bytes. > + - String: name of the export > + > + The client MAY list one or more items of specific information it > + is seeking in the list of information requests, or it MAY specify > + an empty list. The server MUST ignore any information requests > + it does not understand. The server MAY ignore information requests > + that it does not wish to supply for policy reasons (other than > + `NBD_INFO_EXPORT`). Equally the client MAY refuse to negotiate > + if not supplied information it has requested. The server MAY send > + information requests back which are not explicitly requested, but > + the server MUST NOT assume that such information requests are > + understood and respected by the client unless the client explicitly > + asked for them. The client MUST ignore information replies it > + does not understand. Should we state that clients SHOULD NOT request a particular info item more than once in its request list? Do we need to state anything about whether a client may include NBD_INFO_EXPORT in its request list (since that one is mandatory even without being requested)? On the other hand, I don't see what it would add other than verbosity. Looking better, and I'm still feeling comfortable with the amount of tweaks to my qemu patches to implement this change if we go with it. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature