search for: recv_magic

...l NBDMAGICIHAVEOPT <- magic string sent by the server But in this case let's say the server is slow to send the magic string. The call to recv_into_rbuf -> h->sock->ops->recv -> recv returns EWOULDBLOCK (recv_into_rbuf returns 1). Then we stay in the same state (MAGIC.RECV_MAGIC), and return to the main program. At this point if the main program calls nbd_aio_get_direction it would return AIO_DIRECTION_READ. We are expecting to read the socket next. A write on the socket is not possible in this state (so we will not return AIO_DIRECTION_BOTH). I hope that's a bit cl...

...: nbd_connect_uri: poll end: r=1 revents=4 libnbd: debug: nbd5: nbd_connect_uri: event NotifyWrite: CONNECT.START -> CONNECT.CONNECTING libnbd: debug: nbd5: nbd_connect_uri: transition: CONNECT.CONNECTING -> MAGIC.START libnbd: debug: nbd5: nbd_connect_uri: transition: MAGIC.START -> MAGIC.RECV_MAGIC libnbd: debug: nbd5: nbd_connect_uri: poll start: events=1 nbdkit: debug: accepted connection nbdkit: full[1]: debug: newstyle negotiation: flags: global 0x3 libnbd: debug: nbd5: nbd_connect_uri: poll end: r=1 revents=1 libnbd: debug: nbd5: nbd_connect_uri: transition: MAGIC.RECV_MAGIC -> MAGIC....

Very much a work in progress as there are still many tests using qemu-io which are candidates for conversion. You'll notice at the end of test-full.sh that the new test has some duplicated code which looks as if it ought to be refactored into a Python function. When I tried to do that, I got loads of strange Python problems which may indicate bugs in nbdsh itself or problems with my

On 7/6/2023 7:06 PM, Nir Soffer wrote: > > - After calling for 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

This is version 4 of the following sub-series: [libnbd PATCH v3 06/29] lib/utils: introduce xwrite() as a more robust write() [libnbd PATCH v3 07/29] lib/utils: add async-signal-safe assert() [libnbd PATCH v3 08/29] lib/utils: add unit test for async-signal-safe assert() http://mid.mail-archive.com/20230215141158.2426855-7-lersek at redhat.com

...; return -1; + case -1: SET_NEXT_STATE (%.DEAD); return 0; case 0: SET_NEXT_STATE (%FINISH); } return 0; diff --git a/generator/states-magic.c b/generator/states-magic.c index 93c92fc..de8d235 100644 --- a/generator/states-magic.c +++ b/generator/states-magic.c @@ -27,7 +27,7 @@ MAGIC.RECV_MAGIC: switch (recv_into_rbuf (h)) { - case -1: SET_NEXT_STATE (%.DEAD); return -1; + case -1: SET_NEXT_STATE (%.DEAD); return 0; case 0: SET_NEXT_STATE (%CHECK_MAGIC); } return 0; @@ -38,7 +38,7 @@ if (strncmp (h->sbuf.new_handshake.nbdmagic, "NBDMAGIC", 8) != 0) { SE...

This isn't quite finished because not all of the tests or examples have been updated, but it demonstrates an idea: Should we forget about the concept of having multiple connections managed under a single handle? In this patch there is a single ‘struct nbd_handle *’ which manages a single state machine and connection (and therefore no nbd_connection). To connect to a multi-conn server you must

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