similar to: [libnbd] Slight API inconsistency

On Thu, Jul 11, 2019 at 09:35:02AM -0500, Eric Blake wrote: >On 7/11/19 9:23 AM, Martin Kletzander wrote: >> The callback (e.g. for `nbd_block_status`) now has a support for returning >> errors thanks to the last parameter (`int *error`), so it was switched to >> returning void. > >No, the callback still returns int. Where are you seeing it return >void, because

On 7/11/19 9:23 AM, Martin Kletzander wrote: > The callback (e.g. for `nbd_block_status`) now has a support for returning > errors thanks to the last parameter (`int *error`), so it was switched to > returning void. No, the callback still returns int. Where are you seeing it return void, because that's wrong. The documentation states that *error is ignored except when the return is

** INCOMPLETE ** This is the generator change as discussed on the list already. The Python and OCaml bindings are not yet done. It passes all [C only] tests and valgrind. Note that nbd_add_close_callback is inconsistent with other closure types because it passes the user_data parameter after the function. (This is not caused by the current patch, it was already inconsistent). We decided that

Posting now that I got something to compile (at the expense of breaking OCaml bindings), but I'm open to ideas on how to improve it. Eric Blake (2): generator: Tweak print_c_arg_list to take alternate first arg RFC: generator: Handle shared callbacks in Python generator/generator | 556 ++++++++++++++++++++++---------------------- 1 file changed, 280 insertions(+), 276 deletions(-) --

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

On 7/16/19 6:04 AM, Richard W.M. Jones wrote: > A Closure is a list of (usually one, but can be more) closures. In C > there is also a singe ‘void *user_data’ parameter which is passed by > the caller into the function and through as the first parameter of > each callback invocation. > > By grouping the previously separate Opaque and Callback* parameters > together we can

Here are few things I found out when using libnbd that might be perfectly fine or maybe just an oversight, but I wanted to point them out. It's nothing major. When running a program with `nbdkit -U - --run ...`, the $nbd parameter gets expanded to nbd:unix:/path/to/socket. When this string is passed to nbd_connect_uri(), it does not return an error (even though it is not a valid URL), but

I still need to wire in the use of *_notify functions into nbdkit to prove whether it makes the code any faster or easier to maintain, but at least the added example shows one good use case for the new API. Eric Blake (6): api: Add nbd_aio_in_flight generator: Allow DEAD state actions to run generator: Allow Int64 in callbacks states: Prepare for aio notify callback api: Add new

On 6/25/19 8:14 AM, Richard W.M. Jones wrote: > On Tue, Jun 25, 2019 at 02:58:34PM +0200, Martin Kletzander wrote: >> Here are few things I found out when using libnbd that might be perfectly fine >> or maybe just an oversight, but I wanted to point them out. It's nothing major. >> >> When running a program with `nbdkit -U - --run ...`, the $nbd parameter gets

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

[RFC because generated OCaml code needs the same treatment, but I ran out of time to play with that. At least 'make -C python check' passes, although coverage is not complete yet, as there is no python/t/5XX-pread-structured-callback.py...] [Also RFC because I'm not sure if the use of a record type for 'callback' is the best approach or most idiomatic OCaml - but hey, it

As mentioned in the previous patch, there are situations where an aio client wants instant notification when a given command is complete, rather than having to maintain a separate data structure to track all in-flight commands and then iterate over that structure to learn which commands are complete. It's also desirable when writing a server validation program (such as for checking structured

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

Obvious change given the previous patch, so ACK. I do wonder if we should make the notify parameter mandatory (and therefore avoid the duplicate functions). Another trick you might do if feeling really keen is to programmatically generate the notify variants of commands, something like this: let make_notify_variant_of_call ({ args; longdesc } as call) = let args = List.rev args in let

--- docs/libnbd.pod | 73 +++++++++++++++++++++++++++++++++++++++++++++ generator/generator | 52 +++++++++++++++++++++++++++----- lib/handle.c | 32 ++++++++++++++++++++ lib/internal.h | 7 +++++ lib/socket.c | 22 +++++++++++--- podwrapper.pl.in | 3 +- 6 files changed, 177 insertions(+), 12 deletions(-) diff --git a/docs/libnbd.pod b/docs/libnbd.pod index

This works, but there's no time saving and I'm still investigating whether it does what I think it does. Nevertheless I thought I would post it because it (probably) implements the idea I had last night outlined in: https://www.redhat.com/archives/libguestfs/2019-June/msg00010.html The meat of the change is patch 4. Patch 5 is an example which I would probably fold into patch 4 for

A Closure is a list of (usually one, but can be more) closures. In C there is also a singe ‘void *user_data’ parameter which is passed by the caller into the function and through as the first parameter of each callback invocation. By grouping the previously separate Opaque and Callback* parameters together we can avoid the awkward situation where we have to scan through the argument list to try

On Mon, Jun 17, 2019 at 07:07:56PM -0500, Eric Blake wrote: > diff --git a/generator/generator b/generator/generator > index 2614689..ce77f17 100755 > --- a/generator/generator > +++ b/generator/generator > @@ -1305,7 +1305,72 @@ Issue a read command to the NBD server for the range starting > at C<offset> and ending at C<offset> + C<count> - 1. NBD > can

Mutable (Int n) => int *n This can currently only be used for callback arguments of type int (not for other types, nor for any ordinary function arguments), but it could be implemented more generally in future. --- generator/generator | 75 +++++++++++++++++++++++++++++++++++++-------- 1 file changed, 63 insertions(+), 12 deletions(-) diff --git a/generator/generator b/generator/generator

An upcoming patch to add callbacks for aio completion notification wants to expose Int64 as a callback parameter. It's time to wire that up. --- generator/generator | 25 +++++++++++++++---------- 1 file changed, 15 insertions(+), 10 deletions(-) diff --git a/generator/generator b/generator/generator index 45a030f..c5988e2 100755 --- a/generator/generator +++ b/generator/generator @@ -3508,7