search for: error_cb

...h would ordinarily be safe when using the same + * handle from multiple threads. + * + * In each thread, the TLS data is either NULL or contains a pointer + * to a 'struct error_data'. + * + * When it is NULL, it means the stack is empty (in that thread) and + * the default handler (default_error_cb) is installed. + * + * As soon as the current thread calls guestfs_set_error_handler, + * guestfs_push_error_handler, or an error is set in the handle (calls + * like guestfs_int_perrorf and so on), the key is created and + * initialized with a pointer to a real 'struct error_data'. + * + *...

...h would ordinarily be safe when using the same + * handle from multiple threads. + * + * In each thread, the TLS data is either NULL or contains a pointer + * to a 'struct error_data'. + * + * When it is NULL, it means the stack is empty (in that thread) and + * the default handler (default_error_cb) is installed. + * + * As soon as the current thread calls guestfs_set_error_handler, + * guestfs_push_error_handler, or an error is set in the handle (calls + * like guestfs_int_perrorf and so on), the key is created and + * initialized with a pointer to a real 'struct error_data'. + * + *...

Previous discussion here: https://www.redhat.com/archives/libguestfs/2015-June/thread.html#00048 v2: - Use a cleanup handler to release the lock. - Rebase to upstream. Note I have not fixed the problem(s) with error handling (patch 3).

Previously posted in 2015: v1: https://www.redhat.com/archives/libguestfs/2015-June/msg00048.html v2: https://www.redhat.com/archives/libguestfs/2015-June/msg00118.html I have rebased and tidied up the patches, fixing a few spelling mistakes, but they are broadly the same as before. I also ran all the tests, which pass. As with the previous versions, this makes a change to the API, where you

This patch isn't ready to go upstream. In fact, I think we might do a quick 1.30 release soon, and save this patch, and also the extensive changes proposed for the test suite[1], to after 1.30. Currently it is not safe to use the same handle from multiple threads, unless you implement your own mutexes. See: http://libguestfs.org/guestfs.3.html#multiple-handles-and-multiple-threads These

Previously posted in 2015: v1: https://www.redhat.com/archives/libguestfs/2015-June/msg00048.html v2: https://www.redhat.com/archives/libguestfs/2015-June/msg00118.html This series was posted about 4 weeks ago: v3: https://www.redhat.com/archives/libguestfs/2017-June/msg00287.html There is no change in this series except I rebased it against current upstream head and retested. Last time there

Previously discussed here: https://www.redhat.com/archives/libguestfs/2010-August/msg00002.html -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/

The first three patches were posted previously: https://www.redhat.com/archives/libguestfs/2010-July/msg00082.html The last two patches in this series change guestfish -i to use this new code. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to

These three patches (two were previously posted) can do simple operating system inspection in C. Example of use: ><fs> add-ro rhel55.img ><fs> run ><fs> inspect-os /dev/VolGroup00/LogVol00 ><fs> inspect-get-type /dev/VolGroup00/LogVol00 linux ><fs> inspect-get-distro /dev/VolGroup00/LogVol00 rhel ><fs> inspect-get-arch

...h other so it is easier to see how they work hand in hand. > I happen to be looking at our error handling paths. I think we want > virtio_gpu_queue_fenced_ctrl_buffer to call vbuf->resp_cb on errors. /me was thinking about that too. Yes, we will need either that, or a separate vbuf->error_cb callback. That'll be another patch though. > > + /* > > + * We are in the release callback and do NOT want refcount > > + * bo, so do NOT use virtio_gpu_array_add_obj(). > > + */ > > + vbuf->objs = virtio_gpu_array_alloc(1); &g...

...n g->abort_cb; + guestfs_abort_cb r; + + ACQUIRE_LOCK (g); + r = unlocked_get_out_of_memory_handler (g); + RELEASE_LOCK (g); + return r; } void guestfs_set_error_handler (guestfs_h *g, guestfs_error_handler_cb cb, void *data) { + ACQUIRE_LOCK (g); g->error_cb = cb; g->error_cb_data = data; + RELEASE_LOCK (g); } -guestfs_error_handler_cb -guestfs_get_error_handler (guestfs_h *g, void **data_rtn) +static guestfs_error_handler_cb +unlocked_get_error_handler (guestfs_h *g, void **data_rtn) { if (data_rtn) *data_rtn = g->error_cb_data; re...

From: Michael Scherer <misc at zarb.org> Without this, configure will always enable erlang, no matter what argument are passed. Now, we can disable it, even if configure still need the erlang compiler for some obscure reason. --- configure.ac | 10 ++++++---- 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/configure.ac b/configure.ac index 337a3ed..e0bed2f 100644 ---

...r or NULL */ + /* Optional socket directory - this is created on demand only when + * creating a socket whose absolute path in tmpdir would not fit + * into sockaddr_un::sun_path. + */ + char *sockdir; /* Error handler, plus stack of old error handlers. */ guestfs_error_handler_cb error_cb; @@ -758,7 +763,9 @@ extern void guestfs_int_call_callbacks_array (guestfs_h *g, uint64_t event, cons /* tmpdirs.c */ extern int guestfs_int_set_env_tmpdir (guestfs_h *g, const char *tmpdir); extern int guestfs_int_lazy_make_tmpdir (guestfs_h *g); +extern int guestfs_int_lazy_make_sockdir (guest...

Error out early if the path to the socket will not fit into sockaddr_un::sun_path, as we will not be able to connect to it. --- src/launch-unix.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/launch-unix.c b/src/launch-unix.c index 740c554..973e14b 100644 --- a/src/launch-unix.c +++ b/src/launch-unix.c @@ -47,6 +47,12 @@ launch_unix (guestfs_h *g, void *datav, const char

Add new virtio_gpu_cleanup_object() helper function for object cleanup. Wire up callback function for resource unref, do cleanup from callback when we know the host stopped using the resource. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 3 ++- drivers/gpu/drm/virtio/virtgpu_object.c | 19 ++++++++++----

Add new virtio_gpu_cleanup_object() helper function for object cleanup. Wire up callback function for resource unref, do cleanup from callback when we know the host stopped using the resource. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 3 ++- drivers/gpu/drm/virtio/virtgpu_object.c | 19 ++++++++++----

...directory - this is created on demand only when > + * creating a socket whose absolute path in tmpdir would not fit > + * into sockaddr_un::sun_path. > + */ > + char *sockdir; > > /* Error handler, plus stack of old error handlers. */ > guestfs_error_handler_cb error_cb; > @@ -758,7 +763,9 @@ extern void guestfs_int_call_callbacks_array (guestfs_h *g, uint64_t event, cons > /* tmpdirs.c */ > extern int guestfs_int_set_env_tmpdir (guestfs_h *g, const char *tmpdir); > extern int guestfs_int_lazy_make_tmpdir (guestfs_h *g); > +extern int guestfs_int...

These two patches are probably not completely independent, but separating them is a lot of work. With *both* patches applied, all the tests and extra-tests pass. That's no guarantee however that there isn't a mistake, so I don't think this patch is a candidate for the 1.16 branch, until it's had a lot more testing in development. Rich.

...the API, but is used internally to + * emulate the old-style callback API. + */ + void *opaque2; +}; + struct guestfs_h { struct guestfs_h *next; /* Linked list of open handles. */ @@ -133,16 +145,10 @@ struct guestfs_h guestfs_abort_cb abort_cb; guestfs_error_handler_cb error_cb; void * error_cb_data; - guestfs_log_message_cb log_message_cb; - void * log_message_cb_data; - guestfs_subprocess_quit_cb subprocess_quit_cb; - void * subprocess_quit_cb_data; - guestfs_launch_done_cb launch_done_cb; - vo...

This adds most of the hivex APIs directly to the libguestfs API, so that you can read and write Windows Registry hive files from libguestfs without needing to download and upload hive files from the guest. This is analogous to how Augeas APIs are exposed already (guestfs_aug_*) Also, inspection is now done using the new APIs, which fixes the following bug: