similar to: [libnbd] How close are we to declaring a stable API?

On 6/29/19 5:25 AM, Richard W.M. Jones wrote: > As the subject says, how close are we to being able to declare a > stable API for libnbd? > > I believe these are the main topics: > > * Do we need to have an extra thread for writing? I'm unclear about > whether b92392b717 (which allows the state machine to break during > reply processing) means we definitely

On 8/15/19 4:56 AM, Richard W.M. Jones wrote: > Previously the .free function of a callback was not called if the > .callback field was NULL, because the callback as a whole would be > considered to be "null". > > This change allows you to register callbacks where the .callback field > is NULL, but the .free field is != NULL, meaning that the callback is > freed

On Mon, Aug 12, 2019 at 11:00:01PM +0100, Richard W.M. Jones wrote: > On Mon, Aug 12, 2019 at 01:53:56PM -0500, Eric Blake wrote: > > We then have the design question of whether to make an OClosure type, > > where C has two functions nbd_aio_pread and nbd_aio_pread_callback for > > convenience, but where other languages have only a single nbd.aio_pread > > where the

On 8/12/19 1:13 PM, Richard W.M. Jones wrote: > On Mon, Aug 12, 2019 at 11:29:10AM -0500, Eric Blake wrote: >> On 8/12/19 11:08 AM, Richard W.M. Jones wrote: >>> + typedef void (*nbd_free_callback) (void *ptr, void *user_data); >>> + int nbd_add_free_callback (struct nbd_handle *h, >>> + void *ptr, >>> +

As before, but this one has working Python bindings. OCaml still TBD. Rich.

This doesn't include Eric's new APIs, but if you push those then I can rebase this one on top. Rich.

Rather than moving the connection to DEAD, we can just ignore further contexts to the existing command handle, and fail the overall command with the same errno as the failed callback. Eric Blake (2): states: Track cmd->error as errno, not wire value api: Recover from block status callback failure generator/generator | 5 ++- generator/states-reply-simple.c | 2 +-

RFC because this is an API break, but we haven't declared stable API yet. If we like it, I'm working on using libnbd to implement the nbdkit-nbd plugin; knowing whether it is API version 0.1 or 0.2 will be useful. I also dabbled with allowing optional parameters in python, although my OCaml is weak enough that there may be cleaner ways to approach that. Eric Blake (4): api: Add flags

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 8/10/19 8:02 AM, Richard W.M. Jones wrote: > In a future commit we want to add (non-optional) Flags arg. As a step > to doing this, generalize OFlags so it's not tied to just > NBD_CMD_FLAG_*. > > This does not change the C API. > > It does introduce a small change to the OCaml API -- putting related > flags into a submodule, basically renaming them. Note we

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

Since v1: - rebase to applied patches - split out support for Int in callbacks - sort of test that callbacks work in OCaml (see comment in patch 5) - rename API to nbd_pread_structured - expose error as explicit parameter to callback Eric Blake (5): generator: Allow Int in callbacks states: Wire in a read callback states: Add nbd_pread_structured API states: Add tests for

As mentioned in commits 176fc4ea and 609c25f0, our original plan in adding a flags argument to nbd_shutdown was to let us specify different behaviors at the libnbd level, rather than NBD protocol flags (for that, the user has nbd_aio_disconnect). But when we later parameterized OFlags to accept various bitmasks (commit f891340b), we failed to mark nbd_shutdown as using a different bitmask than

libnbd 0.1.5 was released today, but is not yet packaged for Fedora. I'd prefer to bump the minimum version in the pkg-config check in configure.ac, as such, I won't be pushing this patch as-is, but waiting until Fedora does have the newer build. But anyone playing with a self-built libnbd library in the meantime needs this patch to deal with the ABI change. --- plugins/nbd/nbd.c | 11

On Thu, Jul 25, 2019 at 03:19:23PM -0500, Eric Blake wrote: > This looks a bit funny until I read the docs at [1]. When using > kill(2), I'm used to the function call 'kill(pid, 0)' probing for > process existence. But on the command line, kill(1) has the behavior of > sending SIGTERM by default when you omit a signal number (and not > serving as a process existence

We decided to not request the "base:allocation" context by default (if a client wants to use block_status on a different context, then they'd have to get any default request out of the way); however, block status is useless without at least one meta context. This adds a convenience knob for requesting that, and has the nice benefit of working with the --connect command line option

Rich recently patched things to generate one man page per function rather than libnbd-api.3 (nice), but in doing so got stumped by a problem with a fresh git clone (automake fails for any 'include' directive that does not already exist). I've figured out how to hack around it, but the hack requires GNU make. We already use GNU make constructs elsewhere (such as $(wildcard)), but

In a future commit we want to add (non-optional) Flags arg. As a step to doing this, generalize OFlags so it's not tied to just NBD_CMD_FLAG_*. This does not change the C API. It does introduce a small change to the OCaml API -- putting related flags into a submodule, basically renaming them. Note we don't provide guarantees for non-C APIs. --- generator/generator

Now that we have a way to pass Mutable(Int "error") to callbacks, that's a much nicer way for language bindings to use than relying on the value of errno after returning -1. Update the semantics for block status to match what pread_structured does, getting errno out of the equation, and changing things to call the callback for a second context even after an earlier callback failure

I noticed while reading the code that we have a documentation hole that may cause memory leaks for clients that are unaware, in relation to completion callbacks. The situation arises as follows: for all commands with a completion callback, I checked that the code has clean semantics: either nbd_aio_FOO() returns -1 and we never call the callback cleanup, or nbd_aio_FOO() returns a cookie and