search for: bind_unix_socket

This is a series of patches to libnbd and nbdkit adding AF_VSOCK support. On the host side it allows you to start an nbdkit instance which listens on a virtio-vsock socket: $ ./nbdkit -fv --vsock memory 1G ... nbdkit: debug: bound to vsock 2:10809 On the guest side you can then use libnbd to connect to the server: $ ./run nbdsh -c 'h.connect_vsock(2, 10809)' -c

...ose] [-V|--version] + [-v|--verbose] [-V|--version] [--vsock] PLUGIN [[KEY=]VALUE [KEY=VALUE [...]]] nbdkit --dump-config diff --git a/server/internal.h b/server/internal.h index 167da59..5e11e1a 100644 --- a/server/internal.h +++ b/server/internal.h @@ -454,6 +454,8 @@ extern int *bind_unix_socket (size_t *) __attribute__((__nonnull__ (1))); extern int *bind_tcpip_socket (size_t *) __attribute__((__nonnull__ (1))); +extern int *bind_vsock (size_t *) + __attribute__((__nonnull__ (1))); extern void accept_incoming_connections (int *socks, size_t nr_socks) __attribute__((__nonnull__...

v1 was discussed here: https://www.redhat.com/archives/libguestfs/2019-October/thread.html#00100 v2: - Bind to VMADDR_CID_ANY (instead of HOST) and update the documentation accordingly. - Don't bother with SOCK_CLOEXEC fallback path that can never be used. Rich.

...; + * risk of the fd leaking to a plugin's fork() > + */ > + sock = set_cloexec (socket (AF_VSOCK, SOCK_STREAM, 0)); Even better, all known platforms with AF_VSOCK have SOCK_CLOEXEC. Make this #else just be an #error. > +#endif > + if (sock == -1) { > + perror ("bind_unix_socket: socket"); > + exit (EXIT_FAILURE); > + } Also, it wouldn't be that much harder for a followup patch exposing: nbdkit nbd vsock_cid=... vsock_port=... to have our passthrough wrapper call into libnbd's nbd_connect_vsock, and let nbdkit transparently convert from vsock ser...

...connection *conn); +extern void lock_request (struct connection *conn) + __attribute__((__nonnull__ (1))); +extern void unlock_request (struct connection *conn) + __attribute__((__nonnull__ (1))); extern void lock_unload (void); extern void unlock_unload (void); /* sockets.c */ -extern int *bind_unix_socket (size_t *); -extern int *bind_tcpip_socket (size_t *); -extern void accept_incoming_connections (int *socks, size_t nr_socks); -extern void free_listening_sockets (int *socks, size_t nr_socks); +extern int *bind_unix_socket (size_t *) + __attribute__((__nonnull__ (1))); +extern int *bind_tcpip_soc...

...+/* locks.c */ +extern void lock_connection (void); +extern void unlock_connection (void); +extern void lock_request (struct connection *conn); +extern void unlock_request (struct connection *conn); +extern void lock_unload (void); +extern void unlock_unload (void); + /* sockets.c */ extern int *bind_unix_socket (size_t *); extern int *bind_tcpip_socket (size_t *); diff --git a/src/locks.c b/src/locks.c new file mode 100644 index 0000000..6021356 --- /dev/null +++ b/src/locks.c @@ -0,0 +1,115 @@ +/* nbdkit + * Copyright (C) 2013-2018 Red Hat Inc. + * All rights reserved. + * + * Redistribution and use in...

...+/* locks.c */ +extern void lock_connection (void); +extern void unlock_connection (void); +extern void lock_request (struct connection *conn); +extern void unlock_request (struct connection *conn); +extern void lock_unload (void); +extern void unlock_unload (void); + /* sockets.c */ extern int *bind_unix_socket (size_t *); extern int *bind_tcpip_socket (size_t *); diff --git a/src/locks.c b/src/locks.c new file mode 100644 index 0000000..6021356 --- /dev/null +++ b/src/locks.c @@ -0,0 +1,115 @@ +/* nbdkit + * Copyright (C) 2013-2018 Red Hat Inc. + * All rights reserved. + * + * Redistribution and use in...

The patches following do indeed allow you to compile nbdkit.exe, but it does not actually work yet. I'm posting this experimental series more as a work in progress and to get feedback. Note this does not require Windows itself to build or test. You can cross-compile it using mingw64-* packages on Fedora or Debian, and test it [spoiler alert: it fails] using Wine. Rich.

v1 was here: https://www.redhat.com/archives/libguestfs/2019-January/msg00008.html In v2 I have provided two patches: The first patch extends attribute((nonnull)) to most internal functions, but not to the external API. The second patch uses a macro so that attribute((format)) is only used in the public API on GCC or Clang. At least in theory these headers could be used by a C compiler which

The upstream protocol recently promoted NBD_CMD_WRITE_ZEROES from experimental to a documented extension. Exposing support for this allows plugin writers to create sparse files when driven by a client that knows how to use the extension; meanwhile, even if a plugin does not support this extension, the server benefits from less network traffic from the client. Eric Blake (5): protocol: Support

This is an incomplete port to Windows. Currently the server compiles and starts up successfully, but goes into an infinite loop when you connect to it. Nevertheless I think the approach is ready for feedback. This being Windows the changes go quite deep. Rich.

v1 -> v2: - Fixed everything mentioned in the review. Rich.

Somewhat invasive but mostly mechanical change to how plugins are called. This patch is in preparation for adding a second backend subtype for filters. Rich.

Tested via: term1$ qemu-nbd -k $PWD/sock -t -f raw -x foo junk --trace=nbd_\* term2$ ./nbdkit -f -v -e bar nbd socket=$PWD/sock export=foo term3$ qemu-io -t none -f raw nbd://localhost:10809/bar --trace=nbd_\* and checking the traces to see that 'w 0 1' vs. 'w -f 0 1' was able to influence whether the FUA flag showed up at the server in term1. Still to go: figure out how to

Also available here: https://github.com/rwmjones/nbdkit/tree/2020-windows-mingw This is the port to Windows using native Windows APIs (not MSYS or Cygwin). This patch series is at the point where it basically now works. I can run the server with the memory plugin, and access it remotely using guestfish, creating filesystems and so on without any apparent problems. Nevertheless there are many

This is a major rewrite compared to my v1 series, where I've tried a lot harder to ensure that we still accommodate building on Haiku (although I have not actually yet fired up a Haiku VM to try it for myself). I also managed to make the sh plugin fully parallel, on capable platforms. See also my question on patch 10 on whether I've picked the best naming convention. Eric Blake (17):

Also available here: https://github.com/rwmjones/nbdkit/tree/2020-windows-mingw-nolib After a lot of work I have made the port to Windows work without using a separate library. Instead, on Windows only, we build an "import library" (library of stubs) which resolves references to nbdkit_* functions in the main program and fixes up the plugin, basically the first technique outlined in

The first three patches are identical to: https://www.redhat.com/archives/libguestfs/2018-January/msg00079.html "[PATCH nbdkit v2 0/3] Refactor plugin_* functions into a backend" The rest of the patches add filters using the new filter API previously described here: https://www.redhat.com/archives/libguestfs/2018-January/msg00073.html This needs a lot more testing -- and tests --

A combination of the work that both Rich and I have been doing lately, where filters use only the new API with flags on every command that the client can send over the wire (we can then add support for more flags in nbdkit without having to add new callbacks, as NBD adds more flags upstream). Eric Blake (4): protocol: Split flags from cmd field in requests backend: Pass flags argument through