search for: guestfs_impl_

On 07/03/16 13:29, Richard W.M. Jones wrote: > On Sun, Mar 06, 2016 at 05:42:24PM +0200, Matteo Cafasso wrote: >> As discussed in the topic: https://www.redhat.com/archives/libguestfs/2016-March/msg00018.html >> >> I'd like to add to libguestfs the disk forensics capabilities offered by The Sleuth Kit. >> http://www.sleuthkit.org/ >> >> The two APIs

...tput. Your understanding is correct. But the fls0 API still isn't safe because (I assume) it cannot handle filenames containing '\n'. There's another API which handles arbitrary length RStructList returns, which is: guestfs_lxattrlist / guestfs_internal_lxattrlist (see src/file.c:guestfs_impl_lxattrlist and daemon/xattr.c). > What is missing is the higher level implementation which would > pretty much look like the libguestfs_ls API. I need to better > understand how to implement it and suggestions are more than > appreciated. I tried to trace back how the guestfs_find is &g...

Move the generate_all_structs and generate_all_headers functions, previously internal within the implementation of generate_guestfs_h, to be usable by other functions in the same "C" module (but not public). Only code motion. --- generator/c.ml | 163 +++++++++++++++++++++++++++++---------------------------- 1 file changed, 82 insertions(+), 81 deletions(-) diff --git a/generator/c.ml

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.

By splitting up large C files we can make parallel compiles a bit faster. Rich.

...with no optargs. @@ -785,7 +785,7 @@ and generate_internal_actions_h () = pr "\n"; List.iter ( - fun { c_name = c_name; style = style } -> + fun { c_name; style } -> generate_prototype ~single_line:true ~newline:true ~handle:"g" ~prefix:"guestfs_impl_" ~optarg_proto:Argv c_name style @@ -1676,9 +1676,9 @@ and generate_client_actions actions () = in (* For non-daemon functions, generate a wrapper around each function. *) - let generate_non_daemon_wrapper { name = name; c_name = c_name; + let generate_non_daemon_wrapper { n...

Per my previous email: https://www.redhat.com/archives/libguestfs/2017-September/msg00203.html I'd like to talk about requiring a more modern version of the OCaml compiler. These commits show some of the code changes which would be possible with OCaml >= 3.12 [which it turns out we already require by accident] and also with OCaml >= 4.02. The latter is my favoured option. Rich.

v1 -> v2: - Fixed everything mentioned in patch review. - Libdir module is removed as a separate commit. Rich.

...non-blocking so that we don't add + machinery in various bindings. *) + wrapper : bool; (** For non-daemon functions, generate a + wrapper which calls the underlying + guestfs_impl_<name> function. The wrapper + checks arguments and deals with trace + messages. Set this to false for functions + that have to be thread-safe. *) + + (* "Internal" data...

Two (not related to each other) refactorings: Patches 1-12 split configure.ac into smaller files using the m4_include mechanism. Patches 13-15 split out parts of guestfs.pod (ie. guestfs(3)) into three new manual pages: guestfs-hacking(3) - how to extend and contribute to libguestfs guestfs-internals(3) - architecture and internals guestfs-security(3) - security and CVEs Patch 16 is a

This works reliably for me ... Rich.

This patch series moves some files and directories around but is only code motion (or supposed to be). A new directory, common/, is created for all of the common code which is currently shared in random ways between parts of the project. And src/ becomes lib/ (the largest change, but mostly mechanical). In full this series makes the following changes: src/libprotocol -> common/protocol

Previous patch series was posted here: https://www.redhat.com/archives/libguestfs/2017-January/msg00059.html v2 simply extends this patch series to cover the extra directories common/edit, common/progress, common/windows and common/parallel. The only remaining item is to consider whether we should rename mllib to something else, mlcommon was my suggestion. Rich.

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

Split up the huge generator/actions.ml into several smaller files. Rich.