search for: backend_data

...af6de8f532395ea54. --- lib/handle.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/handle.c b/lib/handle.c index bc45d29b2..a47aaafab 100644 --- a/lib/handle.c +++ b/lib/handle.c @@ -399,7 +399,9 @@ guestfs_close (guestfs_h *g) free (g->hv); free (g->backend); free (g->backend_data); +#if HAVE_FUSE free (g->localmountpoint); +#endif guestfs_int_free_string_list (g->backend_settings); free (g->append); guestfs_int_free_error_data_list (g); -- 2.17.1

...g memory and setting g->localmountpoint to NULL. */ return 0; diff --git a/lib/handle.c b/lib/handle.c index 449ab42a6..bc45d29b2 100644 --- a/lib/handle.c +++ b/lib/handle.c @@ -399,6 +399,7 @@ guestfs_close (guestfs_h *g) free (g->hv); free (g->backend); free (g->backend_data); + free (g->localmountpoint); guestfs_int_free_string_list (g->backend_settings); free (g->append); guestfs_int_free_error_data_list (g); -- 2.17.0

...www.mpp.mpg.de/~huber/util/timevaldiff.c + * L<http://www.mpp.mpg.de/~huber/util/timevaldiff.c> */ int64_t guestfs_int_timeval_diff (const struct timeval *x, const struct timeval *y) @@ -148,7 +159,10 @@ guestfs_impl_get_pid (guestfs_h *g) return g->backend_ops->get_pid (g, g->backend_data); } -/* Maximum number of disks. */ +/** + * Returns the maximum number of disks allowed to be added to the + * backend (backend dependent). + */ int guestfs_impl_max_disks (guestfs_h *g) { @@ -159,8 +173,10 @@ guestfs_impl_max_disks (guestfs_h *g) return g->backend_ops->max_disks (g...

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

...4,7 +394,6 @@ guestfs_close (guestfs_h *g) free (g->env_runtimedir); free (g->int_tmpdir); free (g->int_cachedir); - free (g->last_error); free (g->identifier); free (g->program); free (g->path); @@ -403,6 +402,8 @@ guestfs_close (guestfs_h *g) free (g->backend_data); guestfs_int_free_string_list (g->backend_settings); free (g->append); + guestfs_int_free_error_data_list (g); + gl_tls_key_destroy (g->error_data); r = glthread_recursive_lock_destroy (&g->lock); if (r != 0) { /* If pthread_mutex_destroy returns 16 (EBUSY), this...

...a) hash_free (g->pda); free (g->tmpdir); free (g->env_tmpdir); free (g->int_tmpdir); free (g->int_cachedir); - free (g->last_error); free (g->program); free (g->path); free (g->hv); @@ -393,6 +392,8 @@ guestfs_close (guestfs_h *g) free (g->backend_data); guestfs_int_free_string_list (g->backend_settings); free (g->append); + guestfs_int_free_error_data_list (g); + gl_tls_key_destroy (g->error_data); r = glthread_recursive_lock_destroy (&g->lock); if (r != 0) { /* If pthread_mutex_destroy returns 16 (EBUSY), this...

...handle.c +++ b/src/handle.c @@ -316,6 +316,7 @@ guestfs_close (guestfs_h *g) { struct hv_param *hp, *hp_next; guestfs_h **gg; + int r; if (g->state == NO_HANDLE) { /* Not safe to call ANY callbacks here, so ... */ @@ -392,7 +393,24 @@ guestfs_close (guestfs_h *g) free (g->backend_data); guestfs_int_free_string_list (g->backend_settings); free (g->append); - gl_recursive_lock_destroy (g->lock); + r = glthread_recursive_lock_destroy (&g->lock); + if (r != 0) { + /* If pthread_mutex_destroy returns 16 (EBUSY), this indicates + * that the lock is held...

Hi everyone, lately I've been getting familiar with library and working on slight re-layering of the library. It's about having locking layer in public API and tracing one layer below that (let's call it __t_ layer. I'm not very good at making up names, so this is temporary:) ). Then making sure that all generated public stuff call __t_ layer and all other internal stuff

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

QEMU upstream has broken snapshot=on ... again. These two patches stop using it entirely. Instead we run 'qemu-img create' to create overlay disks as required. Note that the libvirt and UML backends were already doing this: The libvirt backend because <transient/> has never worked, and the UML backend was running uml_mkcow because the UML-equivalent syntax of snapshot=on was

...if (g->backend_ops->get_pid == NULL) NOT_SUPPORTED (g, -1, - _("the current backend does not support 'get-pid'")); + _("the current backend does not support ‘get-pid’")); return g->backend_ops->get_pid (g, g->backend_data); } @@ -272,7 +272,7 @@ guestfs_impl_config (guestfs_h *g, STREQ (hv_param, "-full-screen") || STREQ (hv_param, "-std-vga") || STREQ (hv_param, "-vnc")) { - error (g, _("parameter '%s' isn't allowed"), hv_param); + erro...

libguestfs has used double and triple underscores in identifiers. These aren't valid for global names in C++. (http://stackoverflow.com/a/228797) These large but completely mechanical patches change the illegal identifiers to legal ones. Rich.