search for: aio_direction_read

...lambda err, buf=buf: + write_completed (buf, err)) + writes = [] + + poll = select.poll () + + sfd = src.aio_get_fd () + dfd = dst.aio_get_fd () + + sevents = 0 + devents = 0 + if src.aio_get_direction () & nbd.AIO_DIRECTION_READ: + sevents += select.POLLIN + if src.aio_get_direction () & nbd.AIO_DIRECTION_WRITE: + sevents += select.POLLOUT + if dst.aio_get_direction () & nbd.AIO_DIRECTION_READ: + devents += select.POLLIN + if dst.aio_get_direction () & nbd.A...

...or example aio_notify_read(3), can I know that the > next reading from the file descriptor would block? > > No, you have to call again aio_get_direction() and poll again until > the event happens. > Well, what I mean is: After calling aio_notify_read, if aio_get_direction returns AIO_DIRECTION_READ or AIO_DIRECTION_BOTH, can I know that the reading on the file descriptor actually blocked? Or might there be cases when aio_notify_read returns and the next direction includes a read and there is still more data to read on the file descriptor? I guess this is the case, but I must know or the...

...know that the next > reading from the file descriptor would block? > > No, you have to call again aio_get_direction() and poll again until the > event happens. > > > Well, what I mean is: > > After calling aio_notify_read, if aio_get_direction returns > AIO_DIRECTION_READ or AIO_DIRECTION_BOTH, can I know that the > reading on the file descriptor actually blocked? Or might there be > cases when aio_notify_read returns and the next direction includes a > read and there is still more data to read on the file descriptor? It's probably best to have a look...

v1 was here: https://www.redhat.com/archives/libguestfs/2019-August/msg00103.html In v2 I've made several changes: - Fix Python callbacks so if they don't return something which is int-like, we assume they mean to return 0. - Add nbd.Buffer free() method. Read commit message in patch 2 to see what this is about. - Fixed the asynch copy test to deal with the unbelievably

Basically the same as this patch series, but for Python: https://www.redhat.com/archives/libguestfs/2019-August/msg00235.html plus adding the 590 asynch test at the end. Rich.

This doesn't yet work. However it does make me more convinced than ever that we really need to sort out persistent buffer lifetimes in the library (similar to what we did for closures). Rich.

On Wed, Jul 5, 2023 at 3:38?PM Tage Johansson <tage.j.lists at posteo.net> wrote: > As part of the Rust bindings for Libnbd, I try to integrate the > asynchronous (aio_*) functions with Tokio > <https://docs.rs/tokio/latest/tokio/>, the most used asynchronous runtime > in Rust. However, in its eventloop, Tokio uses epoll(7) instead of poll(2) > (which is used internally

I managed to get a build of the async Rust handle compiling on FreeBSD (although the cirrus CI appears to not actually run 'make check' on non-Linux machines, at least when run on my fork): https://gitlab.com/ebblake/libnbd/-/jobs/4985192286 However, I'd really like Tage's review on patch 2 to see if my Rust makes sense. Eric Blake (2): maint: Favor 4-space indent in .rs files

This is a combination of these two earlier series: https://www.redhat.com/archives/libguestfs/2019-August/msg00235.html https://www.redhat.com/archives/libguestfs/2019-August/msg00240.html plus changes to allow .callback = NULL / .free != NULL, and to reduce the complexity of freeing callbacks. Although it's rather long there's nothing complex here. We might consider squashing some

...ot;, (1, 2); (* These calls are proposed for a future version of libnbd, but * have not been added to any released version so far. @@ -3039,7 +3066,7 @@ let first_version = [ *) ] -(* Constants, etc. *) +(* Constants, etc. See also Enums and Flags above. *) let constants = [ "AIO_DIRECTION_READ", 1; "AIO_DIRECTION_WRITE", 2; @@ -3048,6 +3075,9 @@ let constants = [ "READ_DATA", 1; "READ_HOLE", 2; "READ_ERROR", 3; + + "INIT_SPARSE", 1 lsl 0; + "INIT_ZERO", 1 lsl 1; ] let met...

...RInt64; permitted_states = [ Connected ]; shortdesc = "send block status command to the NBD server, with callback on completion"; @@ -2369,17 +2385,12 @@ C<nbd_aio_connect_uri>."; ] -(* Constants, flags, etc. *) +(* Constants, etc. *) let constants = [ "AIO_DIRECTION_READ", 1; "AIO_DIRECTION_WRITE", 2; "AIO_DIRECTION_BOTH", 3; - "CMD_FLAG_FUA", 1 lsl 0; - "CMD_FLAG_NO_HOLE", 1 lsl 1; - "CMD_FLAG_DF", 1 lsl 2; - "CMD_FLAG_REQ_ONE", 1 lsl 3; - "READ_DATA",...

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

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.

I will be following up to this email with four separate threads each addressed to the appropriate single list, with proposed changes to: - the NBD protocol - qemu: both server and client - libnbd: client - nbdkit: server The feature in question adds a new optional NBD_INFO_ packet to the NBD_OPT_GO portion of handshake, adding up to 16 bits of information that the server can advertise to the