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
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
