search for: new_version

...} __attribute__((packed)); -#define OLD_VERSION UINT64_C(0x420281861253) +#define NBD_OLD_VERSION UINT64_C(0x420281861253) /* New-style handshake. */ -struct new_handshake { +struct nbd_new_handshake { char nbdmagic[8]; /* "NBDMAGIC" */ - uint64_t version; /* NEW_VERSION */ + uint64_t version; /* NBD_NEW_VERSION */ uint16_t gflags; /* global flags */ } __attribute__((packed)); -#define NEW_VERSION UINT64_C(0x49484156454F5054) +#define NBD_NEW_VERSION UINT64_C(0x49484156454F5054) /* New-style handshake option (sent by the client to us)...

This may be more a Linux issue but maybe someone can help. I need to know how to compile zaptel for a kernel version different from the one I am running at the moment. Basically I need to do this because I run into trouble when the customer updates the Linux kernel and the next time they restart they do not have the zaptel modules installed. What do I need to do to be able to compile zaptel for

Experimental and only very lightly tested so far. Rich.

...keep an original > version available, in addition to the ones I modify with Polly. However, > initially I will speculate that it is allocated contiguously. Keeping the original version should be easy, as Polly always leaves both versions in the LLVM-IR. At the moment we have if (true) new_version else old_version You could just replace the true with your runtime check. Cheers Tobi

...s = htobe16 (0); + struct fixed_new_option_reply reply; + struct fixed_new_option_reply_info_export reply_export; + char *buffer; + uint16_t info; + + /* TODO: structured reads, block status */ + + /* Try NBD_OPT_GO */ + nbdkit_debug ("trying NBD_OPT_GO"); + opt.version = htobe64 (NEW_VERSION); + opt.option = htobe32 (NBD_OPT_GO); + opt.optlen = htobe32 (sizeof exportnamelen + strlen (export) + + sizeof nrinfos); + if (write_full (h->fd, &opt, sizeof opt) || + write_full (h->fd, &exportnamelen, sizeof exportnamelen) || + write_full (h-&g...

Hi Renato, No, I cannot, but in case it is, I want to take advantage of this. In case it is not, the instrumentation code will detect this at runtime and simply roll back to the original version. I will always keep an original version available, in addition to the ones I modify with Polly. However, initially I will speculate that it is allocated contiguously. Thanks, Alexandra

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

Updated based on other changes that have happened in the meantime: - rely more on cleanup.h (throughout) - split structured read for easier review (patch 2 and 3 were combined in v1) - rely on nbdkit not leaking a server's partial answer (patch 3) - add tests (patch 5) - other bug fixes I found while testing it - drop EOVERFLOW patch for now; it will be separate once upstream NBD protocol

...amp;new_option, sizeof new_option) == -1) { - nbdkit_error ("read: %m"); + if (conn_recv_full (conn, &new_option, sizeof new_option, + "read: %m") == -1) return -1; - } version = be64toh (new_option.version); if (version != NEW_VERSION) { @@ -675,10 +699,9 @@ _negotiate_handshake_newstyle_options (struct connection *conn) switch (option) { case NBD_OPT_EXPORT_NAME: - if (conn->recv (conn, data, optlen) == -1) { - nbdkit_error ("read: %s: %m", name_of_nbd_opt (option)); + if (conn_recv_full...

...let plugins report block - sizes, at which point we should request NBD_INFO_BLOCK_SIZE and - obey any sizes set by server. */ - uint16_t nrinfos = htobe16 (0); - struct fixed_new_option_reply reply; - - nbdkit_debug ("trying NBD_OPT_STRUCTURED_REPLY"); - opt.version = htobe64 (NEW_VERSION); - opt.option = htobe32 (NBD_OPT_STRUCTURED_REPLY); - opt.optlen = htobe32 (0); - if (write_full (h->fd, &opt, sizeof opt)) { - nbdkit_error ("unable to request NBD_OPT_STRUCTURED_REPLY: %m"); - return -1; - } - if (nbdplug_newstyle_recv_option_reply (h, NBD_OPT_STRUCTU...

...let plugins report block - sizes, at which point we should request NBD_INFO_BLOCK_SIZE and - obey any sizes set by server. */ - uint16_t nrinfos = htobe16 (0); - struct fixed_new_option_reply reply; - - nbdkit_debug ("trying NBD_OPT_STRUCTURED_REPLY"); - opt.version = htobe64 (NEW_VERSION); - opt.option = htobe32 (NBD_OPT_STRUCTURED_REPLY); - opt.optlen = htobe32 (0); - if (write_full (h->fd, &opt, sizeof opt)) { - nbdkit_error ("unable to request NBD_OPT_STRUCTURED_REPLY: %m"); - return -1; - } - if (nbdplug_newstyle_recv_option_reply (h, NBD_OPT_STRUCTU...

...e42444d41474943) /* ASCII "NBDMAGIC" */ #define NBD_OLD_VERSION UINT64_C(0x420281861253) /* New-style handshake. */ struct nbd_new_handshake { - char nbdmagic[8]; /* "NBDMAGIC" */ + uint64_t nbdmagic; /* NBD_MAGIC */ uint64_t version; /* NBD_NEW_VERSION */ uint16_t gflags; /* global flags */ } NBD_ATTRIBUTE_PACKED; -#define NBD_NEW_VERSION UINT64_C(0x49484156454F5054) +#define NBD_NEW_VERSION UINT64_C(0x49484156454F5054) /* ASCII "IHAVEOPT" */ /* New-style handshake option (sent by the client to us). */ struct nbd_new_...

I'm hoping to implement .extents for the nbd plugin; this is a prerequisite. I'm not sure about patch 3 - if we like it, I'll squash it to 2, if we don't, I think we are okay just dropping it. I'm also wondering if we have to worry about malicious plugins that don't populate the entire .pread buffer in an effort to get nbdkit to expose portions of the heap; my patch 7 loses

...for (nr_options = 0; nr_options < MAX_NR_OPTIONS; ++nr_options) { - if (conn_recv_full (conn, &new_option, sizeof new_option, - "reading option: conn->recv: %m") == -1) - return -1; - - version = be64toh (new_option.version); - if (version != NEW_VERSION) { - nbdkit_error ("unknown option version %" PRIx64 - ", expecting %" PRIx64, - version, NEW_VERSION); - return -1; - } - - /* There is a maximum option length we will accept, regardless - * of the option type. - */...

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

Patch 1 played with an early draft of Rich's Fedora 30 libnbd package: https://bugzilla.redhat.com/show_bug.cgi?id=1713767#c17 Note that comment 21 provides a newer package 0.1.1-1 with a different API; and that libnbd has more unreleased API changes in the pipeline (whether that will be called 0.2 or 0.1.2); so we'll have to tweak things based on what is actually available in distros.

libnbd-0.1.2-1 is now available in Fedora 29/30 updates-testing, although it was not compiled against libxml2 so it lacks uri support (I ended up testing patch 4 with a self-built libnbd). Diffs since v1 - rebase to master, bump from libnbd 0.1 to 0.1.2, add URI support, better timing results Still not done - patch 5 needs associated tests Eric Blake (5): nbd: Check for libnbd nbd:

These are a couple of patches in preparation for the Block Status implementation. While the patches (especially the second one) are very large they are really just elementary code motion. Rich.

...exportsize), + sizeof old - offsetof (struct old_handshake, exportsize))) { + nbdkit_error ("unable to read old handshake: %m"); + goto err; + } + h->size = be64toh (old.exportsize); + h->flags = be16toh (old.eflags); + } + else if (version == NEW_VERSION) { + uint16_t gflags; + uint32_t cflags; + struct new_option opt; + struct new_handshake_finish finish; + size_t expect; + + if (read_full (h->fd, &gflags, sizeof gflags)) { + nbdkit_error ("unable to read global flags: %m"); + goto err; + } + cfla...

libnbd-0.1.4-1 is now available in Fedora 29/30 updates testing. Diffs since v2 - rebase to master, bump from libnbd 0.1.2 to 0.1.3+, add tests to TLS usage which flushed out the need to turn relative pathnames into absolute, doc tweaks Now that the testsuite covers TLS and libnbd has been fixed to provide the things I found lacking when developing v2, I'm leaning towards pushing this on