search for: get_fd

....c b/lib/crypto.c index 3f7c744..e0f173f 100644 --- a/lib/crypto.c +++ b/lib/crypto.c @@ -181,6 +181,12 @@ tls_send (struct nbd_handle *h, return r; } +static bool +tls_pending (struct socket *sock) +{ + return gnutls_record_check_pending (sock->u.tls.session) > 0; +} + static int tls_get_fd (struct socket *sock) { @@ -209,6 +215,7 @@ tls_close (struct socket *sock) static struct socket_ops crypto_ops = { .recv = tls_recv, .send = tls_send, + .pending = tls_pending, .get_fd = tls_get_fd, .close = tls_close, }; diff --git a/lib/internal.h b/lib/internal.h index 5b6152b.....

...l +++ b/common/mltools/tools_utils.ml @@ -408,9 +408,7 @@ and do_run ?(echo_cmd = true) ?stdout_fd ?stderr_fd args = fd in try - let app = - if Filename.is_relative app then which app - else (Unix.access app [Unix.X_OK]; app) in + let app = which app in let outfd = get_fd Unix.stdout stdout_fd in let errfd = get_fd Unix.stderr stderr_fd in if echo_cmd then diff --git a/dib/cmdline.ml b/dib/cmdline.ml index 220350d9d..11ff57341 100644 --- a/dib/cmdline.ml +++ b/dib/cmdline.ml @@ -251,17 +251,7 @@ read the man page virt-dib(1). if elements = [] then...

nbdkit 1.2 as a server waits for read() to see EOF, even after the client has sent NBD_CMD_DISC. That was fixed in mbdkit 1.4; and most modern NBD servers are smarter than this (they close() the write end of their traffic soon after NBD_CMD_DISC). But it's easy enough to revert nbdkit commit c70616f8 to get back to a server with the same behavior as the older nbdkit, at which point both

...ls.ml b/mllib/common_utils.ml index 73546d7..0008d3a 100644 --- a/mllib/common_utils.ml +++ b/mllib/common_utils.ml @@ -825,29 +825,70 @@ let external_command ?(echo_cmd = true) cmd = ); lines +let run_commands ?(echo_cmd = true) cmds = + let res = Array.make (List.length cmds) 0 in + let get_fd default = function + | None -> + default + | Some fd -> + Unix.set_close_on_exec fd; + fd + in + let pids = + mapi ( + fun i (args, out, err) -> + let app = List.hd args in + try + let app = + if Filename.is_relative app then...

...ut_chan ?stderr_chan in + match run_res with + | Either (pid, app, outfd, errfd) -> + let _, stat = Unix.waitpid [] pid in + do_teardown app outfd errfd stat + | Or code -> + code + +and do_run ?(echo_cmd = true) ?stdout_chan ?stderr_chan args = let app = List.hd args in + let get_fd default = function + | None -> + default + | Some fd -> + Unix.set_close_on_exec fd; + fd + in try let app = if Filename.is_relative app then which app else (Unix.access app [Unix.X_OK]; app) in - let pid = - Unix.create_process app (Array.o...

I'm having major problems with the 10/4 Wine release. Currently the only thing I really use Wine for is Eudora Light 3.0.5. The most stable release for me thus far has been wine-20010112, which is what I'm using right now. Most of the releases since then have had window problems with Eudora-- messages having too much blank space, strange things. So I tried 1004, and it has a new

--- common/mlstdutils/std_utils_tests.ml | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/common/mlstdutils/std_utils_tests.ml b/common/mlstdutils/std_utils_tests.ml index 81f512cbf..f7b0247a4 100644 --- a/common/mlstdutils/std_utils_tests.ml +++ b/common/mlstdutils/std_utils_tests.ml @@ -29,6 +29,11 @@ let assert_equal_int = assert_equal ~printer:(fun x -> string_of_int x)

Hey all Have a very strange problem in slack 8, using wine 20011004. First noticed this with counterstrike, than checked with other programs that should access the net. I get this error, and programs fail: fixme:winsock:_get_sock_fd handle 304 is not a socket (GLE 6) Documentation seems to imply that if I can get on the net with linux, I should be able to use wine with it. Weirdest part is

...struct socket *sock, void *buf, size_t len); ssize_t (*send) (struct nbd_handle *h, - struct socket *sock, const void *buf, size_t len); + struct socket *sock, const void *buf, size_t len, int flags); bool (*pending) (struct socket *sock); int (*get_fd) (struct socket *sock); int (*close) (struct socket *sock); diff --git a/lib/socket.c b/lib/socket.c index 084398b..8555855 100644 --- a/lib/socket.c +++ b/lib/socket.c @@ -42,11 +42,11 @@ socket_recv (struct nbd_handle *h, struct socket *sock, void *buf, size_t len) static ssize_t socket_se...

...- ssize_t (*send) (struct socket *sock, const void *buf, size_t len); + ssize_t (*recv) (struct nbd_handle *h, + struct socket *sock, void *buf, size_t len); + ssize_t (*send) (struct nbd_handle *h, + struct socket *sock, const void *buf, size_t len); int (*get_fd) (struct socket *sock); int (*close) (struct socket *sock); }; diff --git a/lib/socket.c b/lib/socket.c index df933be..f48e455 100644 --- a/lib/socket.c +++ b/lib/socket.c @@ -30,7 +30,7 @@ #include "internal.h" static ssize_t -socket_recv (struct socket *sock, void *buf, size_t l...

I rethought this again, as I think that it's a dangerous assumption to bake qemu-img measure output into our API. This patch series runs qemu-img measure behind the scenes, but then parses the output and sums it to a single number which we print. Doing that required a bit of reworking, moving the Jansson [JSON parser] bindings from virt-builder into the common directory and a couple of other

Appears to have a measurable benefit, see 3/3 for test results. Rich.

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

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