Re: [Libguestfs] [PATCH libnbd 3/4] api: Add nbd_connect_socket.
On 10/4/19 2:50 PM, Richard W.M. Jones wrote:
This allows us to connect directly to a connected socket. How
exactly
the socket is created and connected to the NBD server is left up to
the main program.
The only real complexity in this patch is allowing file descriptors to
be passed to libnbd APIs. Luckily in C and Python we can treat them
exactly as integers, and in OCaml they are also integers but with a
different type.
---
generator/generator | 72 ++++++++++++++++++++++++++++++++++++---------
lib/connect.c | 47 +++++++++++++++++++++++++++++
2 files changed, 105 insertions(+), 14 deletions(-)
+ "connect_socket", {
+ default_call with
+ args = [ Fd "sock" ]; ret = RErr;
+ permitted_states = [ Created ];
+ shortdesc = "connect directly to a connected socket";
+ longdesc = "\
+Pass a connected socket (file descriptor) which libnbd will
+talk to. The program is responsible for connecting this
+somehow to an NBD server. Once the socket is passed to
+libnbd it is the responsibility of libnbd. Libnbd may
+read and write to it, set it to non-blocking, etc., and
+will finally close it when the handle is closed. The
+program must no longer use the socket.";
+ };
Do we want a mode where we can hand a socket to libnbd that has already
completed handshake phase and is immediately ready for transaction
phase? I've seen posts describing alternative programs that do their
own handshake before using ioctls to hand an open socket to the kernel
kvm module, which only needs to know the size and flags associated with
the socket, to proceed to use it without further negotiation. Having
such a mode would allow libnbd instead of the kernel ioctl to be used in
the same manner. But having that as a separate API rather than trying
to cram it into this one is fine. (And same counterpart question for
nbdkit: do we want a mode where nbdkit can be handed an already-open
socket and details about what flags the client side has been told, and
skip handshake straight into serving client transaction requests)
Series looks great to me.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org