search for: guestfs_first_priv

...n machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -------------- next part -------------- >From 9cebd2178ffc99a233af32f2477ef4c0f84f3f1c Mon Sep 17 00:00:00 2001 From: Richard W.M. Jones <rjones at redhat.com> Date: Mon, 14 Mar 2011 13:19:47 +0000 Subject: [PATCH] New APIs: guestfs_first_private, guestfs_next_private to walk over the private data area. This commit adds new APIs for walking over the keys and pointers in the private data area associated with each handle (note this is only applicable to the C API). --- .gitignore | 1 + capitests/Makefile.am...

The safe_malloc (etc) functions call g->abort_fn on failure. That's not appropriate for language bindings, and we never intended that these internal functions be used from language bindings, that was just a historical accident. This patch series removes any external use of the safe_* functions. Rich.

.../ @@ -101,9 +105,20 @@ guestfs_get_private (guestfs_h *g, const char *key) return NULL; } +void * +guestfs_get_private (guestfs_h *g, const char *key) +{ + void *r; + + ACQUIRE_LOCK (g); + r = unlocked_get_private (g, key); + RELEASE_LOCK (g); + return r; +} + /* Iterator. */ -void * -guestfs_first_private (guestfs_h *g, const char **key_rtn) +static void * +unlocked_first_private (guestfs_h *g, const char **key_rtn) { if (g->pda == NULL) return NULL; @@ -122,7 +137,18 @@ guestfs_first_private (guestfs_h *g, const char **key_rtn) } void * -guestfs_next_private (guestfs_h *g, const...

From: "Richard W.M. Jones" <rjones at redhat.com> --- configure.ac | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index fa97479..6e42423 100644 --- a/configure.ac +++ b/configure.ac @@ -141,6 +141,10 @@ if test "$gl_gcc_warnings" = yes; then # Work around warning in src/inspect.c. This seems to be a bug in gcc

The existing mechanism was clunky, slow and used ~ 10 MB of local disk. Rich.

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

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

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

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.