On 5 Apr 2016, at 22:26, Eric Blake <eblake@...696...> wrote: > In particular, I had a question about the ideal layout of the data in > NBD_REP_SERVER; I'd like some discussion on that point before posting a > cleanup patch. Hmmm... Yes. In particular: > NBD_REP_SERVER (2) > > A description of an export. Data: > > • 32 bits, length of name (unsigned); MUST be no larger than the reply packet header length - 4 > • Name of the export, as expected by NBD_OPT_EXPORT_NAME (note that the length of name does NOT include a NUL terminator) > • If length of name < (reply packet header length - 4), then the rest of the data contains some implementation-specific details about the export. This is not currently implemented, but future versions of nbd-server may send along some details about the export. Therefore, unless explicitly documented otherwise by a particular client request, this field is defined to be UTF-8 encoded data suitable for direct display to a human being; with no embedded or terminating NUL characters. > The experimental INFO extension (see below) is a client request where the extra data has a definition other than a UTF-8 message. I'm not sure reordering those fields was a great idea :-/ -- Alex Bligh
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail