similar to: [libnbd PATCH v2 0/3] Improve type-safety of ocaml/golang getters

Natural fallout after my recent testsuite additions that fixed a couple of ocaml bugs in the setters. However, on at least the OCaml code, I'm not sure what we should do if a newer libnbd ever returns a bit that an older NBD.mli was not expecting at the time the OCaml compiler ran (see below). I'm also not sure if there is a more efficient way to avoid outputting Val_FOO() converters for

In v2: - now based on my proposal to add LIBNBD_SHUTDOWN_IMMEDIATE - four flags instead of two: STRICT_FLAGS is new (patch 4), and STRICT_BOUNDS is separate from STRICT_ZERO_SIZE (patch 5) - various refactorings for more shared code and less duplication Eric Blake (5): api: Add xxx_MASK constant for each Flags type generator: Refactor filtering of accepted OFlags api: Add

Now that we have a distinct branch in the generator when returning an enum or bitmask that cannot fail, we can use it in OCaml for symmetry, so that the result of a get function can be plugged into a set function without manual conversion of an integer. This includes the use of the recently-added UNKNOWN catch-all for encoding C values returned by a newer libnbd.so than when the OCaml bindings

Now that we have a distinct branch in the generator when returning an enum or bitmask that cannot fail, we can use it in OCaml for symmetry, so that the result of a get function can be plugged into a set function without manual conversion of an integer. While at it, add an abort() if OCaml ever hands us a value we can't translate to a C int (that one is unreachable per OCaml type safety), or

Document and make it easier for applications to determine which bitmask values were supported at compile time. Also, generating bitmask values in hex tends to be more legible than in decimal, as it makes it obvious that the values are intended for bitwise operations. And it doesn't hurt that this reduces churn in some of the tests if new bits are added. --- docs/libnbd.pod

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

Now that we have a distinct branch in the generator when returning an enum or bitmask that cannot fail, we can use it in Golang for symmetry, so that the result of a get function can be plugged into a set function without a trip through other types. --- generator/GoLang.ml | 12 ++++++------ .../libnbd/libnbd_110_defaults_test.go | 6 +++---

For commands with long names and/or short descriptors, you can end up going over 72 characters in the first line of the man page (causing podwrapper to complain). Wrap these lines. --- generator/generator | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/generator/generator b/generator/generator index 7d3f656..ad1cb6b 100755 --- a/generator/generator +++ b/generator/generator

Now runs a complete set of tests, notably including the AIO test. File descriptors are passed in and out as plain ints (instead of *os.File) for a couple of reasons: (1) We have to pass the plain int to syscall.Select. (2) Turning an fd into an os.File causes golang to set the blocking flag which is deeply unhelpful. Rich.

For now, there is no change to the generated code (although the man pages are slightly improved), but this will make it easier for later patches to improve OCaml and Golang bindings so that set/get pairs are typed symmetrically. --- generator/API.ml | 16 ++++++++++------ generator/API.mli | 2 ++ generator/C.ml | 20 ++++++++++++-------- generator/GoLang.ml | 13 ++++++++++++-

This largish series adds several new features to the generator. Enum maps to enumerated types (like enum in C). The only current use for this is replacing the nbd_set_tls (nbd, 0/1/2) parameter with LIBNBD_TLS_DISABLE, LIBNBD_TLS_ALLOW, LIBNBD_TLS_REQUIRE (and natural equivalents in other programming languages). Flags maps to any uint32_t bitmask. It is basically a non-optional, generalized

On Sat, Sep 05, 2020 at 08:40:58PM -0500, Eric Blake wrote: > diff --git a/generator/API.mli b/generator/API.mli > index 712e837..e45b5c0 100644 > --- a/generator/API.mli > +++ b/generator/API.mli > @@ -78,6 +78,8 @@ and ret = > | RString (** return a newly allocated string, > caller frees, NULL for error *) > | RUInt

On Fri, Sep 11, 2020 at 04:49:55PM -0500, Eric Blake wrote: > The next strict knob: allow the user to pass unknown flags across the > wire (this is different than passing a known flag at the wrong time). > > It is interesting to note that NBD only permits 16 bits of flags, but > we have a signature that takes uint32_t; if we wanted, we could pack > libnbd-specific flags in the

When LIBNBD_TLS_ALLOW is used we don't have a way to find out if TLS was really negotiated. This adds a flag and a way to read it back. Unfortunately there is no test yet, because LIBNBD_TLS_ALLOW is not tested -- it really should be but requires quite a complicated set of tests because ideally we'd like to find out whether it falls back correctly for all supported servers. --- TODO

On Sat, Sep 05, 2020 at 08:40:57PM -0500, Eric Blake wrote: > Natural fallout after my recent testsuite additions that fixed a > couple of ocaml bugs in the setters. However, on at least the OCaml > code, I'm not sure what we should do if a newer libnbd ever returns a > bit that an older NBD.mli was not expecting at the time the OCaml > compiler ran (see below). I'm also

Right now, libnbd has refused to issue a command not advertised as supported by a server, mainly because the NBD protocol does not guarantee what the server will do, and libnbd would rather stay in sync with the server than drop the connection. However, for integration purposes, it can be handy to coerce libnbd into sending something to see how the server will react (whether it be an extension

In this patch series we use the newly introduced free callback on the completion function to dererence the OCaml NBD.Buffer. I will make the same kind of change for Python later in a separate series. The completion function is always called at the C level, even if the OCaml program didn't use the optional argument. That's because the free callback doesn't run otherwise. There is a

On Mon, Sep 07, 2020 at 09:38:15AM -0500, Eric Blake wrote: > On 9/7/20 9:13 AM, Richard W.M. Jones wrote: > > >>+++ b/generator/C.ml > >>@@ -66,15 +66,15 @@ let errcode_of_ret = > >> function > >> | RBool | RErr | RFd | RInt | RInt64 | RCookie -> Some "-1" > >> | RStaticString | RString -> Some "NULL" >

This feature is roughly finished now, although it needs a few more tests and some examples. It's pretty much up to par with all the other bindings, but it lacks a completely safe AIO buffer. It won't stop you from freeing the buffer too early) because golang's GC inexplicably lacks a way to declare a root from C. I can probably do it with a global variable and ref counting on the

Patches 1-4 are basically uncontroversial, straightforward refactoring and IMHO we should just push them. Possibly 1-3 should be squashed together, but I posted them separately so they are easier to review. Patches 5 and 6 together implement OClosure. Patch 5 adds the feature and is simple to understand. Patch 6 changes the Closure completion callbacks into OClosure, but because it doesn't