On 5 Apr 2016, at 22:26, Eric Blake <ebl...@redhat.com> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
