nbd/server: Enable initial support for extended headers
authorEric Blake <eblake@redhat.com>
Mon, 25 Sep 2023 19:22:35 +0000 (14:22 -0500)
committerEric Blake <eblake@redhat.com>
Thu, 5 Oct 2023 16:02:08 +0000 (11:02 -0500)
commit9c1d26143764dc53c19d872de4f8a9f820e05177
treea47d804af86596ed5d442061e8917a1cf49930a7
parentbcc16cc19eb87889c92b71a8cde77f502e7e19be
nbd/server: Enable initial support for extended headers

Time to start supporting clients that request extended headers.  Now
we can finally reach the code added across several previous patches.

Even though the NBD spec has been altered to allow us to accept
NBD_CMD_READ larger than the max payload size (provided our response
is a hole or broken up over more than one data chunk), we are not
planning to take advantage of that, and continue to cap NBD_CMD_READ
to 32M regardless of header size.

For NBD_CMD_WRITE_ZEROES and NBD_CMD_TRIM, the block layer already
supports 64-bit operations without any effort on our part.  For
NBD_CMD_BLOCK_STATUS, the client's length is a hint, and the previous
patch took care of implementing the required
NBD_REPLY_TYPE_BLOCK_STATUS_EXT.

We do not yet support clients that want to do request payload
filtering of NBD_CMD_BLOCK_STATUS; that will be added in later
patches, but is not essential for qemu as a client since qemu only
requests the single context base:allocation.

Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Message-ID: <20230925192229.3186470-19-eblake@redhat.com>
docs/interop/nbd.txt
nbd/server.c