Eric, >> @@ -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. Could do, but it's 32 bits elsewhere for export name. I was thinking people might want a generic 'read export name' function. >> + - 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? Yes (in fact let's make that a MUST). And no doubt that servers MAY send things in any order. > 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. I didn't prohibit it for exactly that reason > 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. I tried quite hard to make that 'none at all' but couldn't quite get away with it. I think it's pretty trivial for gonbdserver. A chatty server that doesn't care about whether the client understands block size constraints can simply send everything. I'll wait for Wouter to have a poke around before doing v5. -- Alex Bligh
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail