similar to: [PATCH libnbd] lib: Copy nbd-protocol.h from nbdkit 1.15.3.

Some further small changes are made to allow this header to be used from arbitrary ISO C compilers. It can now be used from other projects. --- common/protocol/Makefile.am | 2 ++ common/protocol/nbd-protocol.h | 38 ++++++++++++++++++++-------------- 2 files changed, 24 insertions(+), 16 deletions(-) diff --git a/common/protocol/Makefile.am b/common/protocol/Makefile.am index

On 9/24/19 4:07 PM, Richard W.M. Jones wrote: > Eventually nbdkit will install this as a public header file and we > will be able to consume it from $includedir. In the mean time > synchronize with the copy in nbdkit. > --- > lib/nbd-protocol.h | 57 +++++++++++++++++++++++----------------------- > 1 file changed, 28 insertions(+), 29 deletions(-) > > /* Newstyle

On Tue, Sep 24, 2019 at 05:24:34PM -0500, Eric Blake wrote: > On 9/24/19 4:07 PM, Richard W.M. Jones wrote: > > /* New-style handshake server reply when using NBD_OPT_EXPORT_NAME. > > * Modern clients use NBD_OPT_GO instead of this. > > @@ -167,7 +167,7 @@ struct nbd_new_handshake_finish { > > uint64_t exportsize; > > uint16_t eflags; /*

We should have only one NBD protocol file. Let's make nbdkit's version the canonical one, and use it in libnbd. Rich.

Diff against libnbd’s copy of this file, and change this one until it matches. --- common/protocol/nbd-protocol.h | 76 +++++++++++++++++----------- server/protocol-handshake-newstyle.c | 26 +++++----- server/protocol-handshake-oldstyle.c | 4 +- server/protocol.c | 25 ++++----- tests/test-layers.c | 14 ++--- 5 files changed, 81 insertions(+), 64

On Wed, Sep 25, 2019 at 09:46:13AM +0100, Richard W.M. Jones wrote: > On Tue, Sep 24, 2019 at 05:24:34PM -0500, Eric Blake wrote: > > On 9/24/19 4:07 PM, Richard W.M. Jones wrote: > > > /* New-style handshake server reply when using NBD_OPT_EXPORT_NAME. > > > * Modern clients use NBD_OPT_GO instead of this. > > > @@ -167,7 +167,7 @@ struct

Updated in https://github.com/libguestfs/nbdkit/commit/XXX Requires tweaks to our handling of nbd magic. --- Will update with a real URL, if we like it. lib/nbd-protocol.h | 35 ++++++++++++++++------------------- generator/states-magic.c | 2 +- 2 files changed, 17 insertions(+), 20 deletions(-) diff --git a/lib/nbd-protocol.h b/lib/nbd-protocol.h index fe4d451..bdd1ef2 100644 ---

Similar to the recent --mask-handshake command line added to nbdkit to test client fallbacks to crippled servers, it can be worth testing server fallbacks to crippled clients. And just as we have exposed whether the client will request structured replies, we can also expose whether the client will understand various handshake flags from the NBD protocol. Of course, we default to supporting all

More nbd-protocol.h improvements Eric Blake (2): common/protocol: Switch nbdmagic to uint64_t common/protocol: Declare additional constants common/protocol/nbd-protocol.h | 16 ++++++++++------ server/protocol-handshake-newstyle.c | 2 +- server/protocol-handshake-oldstyle.c | 2 +- plugins/nbd/nbd-standalone.c | 2 +- tests/test-layers.c | 2 +- 5 files

Qemu was able to demonstrate that knowing whether a zero operation is fast is useful when copying from one image to another: there is a choice between bulk pre-zeroing and then revisiting the data sections (fewer transactions, but depends on the zeroing to be fast), vs. visiting every portion of the disk only once (more transactions, but no time lost to duplicated I/O due to slow zeroes). As

When structured replies are negotiated, the server may advertise support for the DF flag (the server promises to return at most one data/hole chunk, or to fail with NBD_EOVERFLOW if the chunk would be too large). As both nbdkit and qemu-nbd support this flag (the former only trivially, but the latter by not compressing holes over the wire), it is worth exposing to clients, if only for testing

The DF flag is only available to clients that negotiated structured replies, and even then, the spec does not require that it be implemented. However, since our current implementation can't fragment NBD_CMD_READ replies, we trivially implement the flag (by ignoring it); we don't even have to pass it on to the plugins. Enhance some documentation about sparse reads while at it (when we

On Thu, Mar 28, 2019 at 10:44:42PM -0500, Eric Blake wrote: > The DF flag is only available to clients that negotiated structured > replies, and even then, the spec does not require that it be > implemented. However, since our current implementation can't fragment > NBD_CMD_READ replies, we trivially implement the flag (by ignoring > it); we don't even have to pass it on to

Necessary when writing a client that wants to avoid unnecessary EINVAL errors from sending unaligned requests. At some point, we may want to add synchronous convenience API wrappers that do request splitting or read-modify-write to obey server constraints while still appearing to the library client as accepting any possible request. But such a wrapper should only be synchronous and not copied to

On Fri, Mar 29, 2019 at 12:43:33PM +0000, Richard W.M. Jones wrote: >On Thu, Mar 28, 2019 at 10:44:42PM -0500, Eric Blake wrote: >> The DF flag is only available to clients that negotiated structured >> replies, and even then, the spec does not require that it be >> implemented. However, since our current implementation can't fragment >> NBD_CMD_READ replies, we

Qemu was able to demonstrate that knowing whether a zero operation is fast is useful when copying from one image to another: there is a choice between bulk pre-zeroing and then revisiting the data sections (fewer transactions, but depends on the zeroing to be fast), vs. visiting every portion of the disk only once (more transactions, but no time lost to duplicated I/O due to slow zeroes). As

The NBD protocol is adding an extension for servers to report the initial state of the image (for now, whether it is sparse and/or reads as all zeroes). Time to expose this to clients, via the new API nbd_get_init_flags(). The patch requires refreshing the nbd-protocol.h file from a corresponding contemporary nbdkit commit. Testing is possible with recent enough qemu. --- .gitignore

On 6/9/23 04:17, Eric Blake wrote: > In order to more easily add a third reply type with an even larger > header, but where the payload will look the same for both structured > and extended replies, it is nicer if simple and structured replies are > nested inside the same layer of sbuf.reply.hdr. Doing this also lets > us add an alias for accessing the cookie directly without

In preparation for installing this header as a common public header for use by other projects, rename it. --- common/protocol/Makefile.am | 10 +++++----- common/protocol/{protocol.h => nbd-protocol.h} | 6 +++--- common/protocol/protostrings.sed | 6 +++--- plugins/nbd/nbd-standalone.c | 2 +- server/protocol-handshake-newstyle.c

Proposal for new APIs to list exports. The general shape of the API can probably best be seen from the examples/list-exports.c example. Rich.