similar to: [PATCH 0/5] generator: daemon: Various simplifications to stubs code.

These 3 patches implement support for APIs which must accept a mountable, but don't update apis which must return mountables. Matt

This type is initially identical to Device. --- generator/bindtests.ml | 2 +- generator/c.ml | 7 +++++-- generator/csharp.ml | 6 ++++-- generator/daemon.ml | 4 ++-- generator/erlang.ml | 6 +++--- generator/fish.ml | 8 ++++---- generator/gobject.ml | 11 ++++++----- generator/haskell.ml | 11 +++++++---- generator/java.ml | 10 +++++-----

This started as a simple warning-elimination change. I'll get back to that series shortly ;-) It turned into a factorization and constification exercise during which I got a taste of ocaml. Thanks to Rich Jones for help with a few snippets in generator.ml. The overall result is that many previously-manually-maintained bits from daemon/*.c functions are now hoisted into the automatically-

In the kernel and qemu communities it is routine for patches that will be backported to stable branches to be posted for review. I'm proposing we do the same for libguestfs stable branches. All of the attached have been tested with 'make check-release'. Rich.

v1 was here: https://www.redhat.com/archives/libguestfs/2020-February/msg00220.html This patch series is a little bit better. It's still a bit of a hack. The _real_ fix for this is outlined in the TODO file (see patch 1) but that requires a lot more work than we could do before 1.42 is released, unless we delay 1.42 for a lot longer. I'm hoping with this to have something which works

For Device parameters we expect a block device name. However we were only testing for "/dev/..." and so chardevs (from the appliance) could be passed here, resulting in strange effects. This adds a function is_device_parameter which tests for a valid block device name. For Dev_or_Path parameters much the same, except we can also use the is_device_parameter function elsewhere in the

Add a macro DUP_RESOLVE_DEVICE_OR_PATH to resolve path or device. Signed-off-by: Wanlong Gao <gaowanlong at cn.fujitsu.com> --- daemon/daemon.h | 18 ++++++++++++++++++ daemon/mount.c | 13 ++----------- po/POTFILES | 8 ++++++++ 3 files changed, 28 insertions(+), 11 deletions(-) diff --git a/daemon/daemon.h b/daemon/daemon.h index 85eec45..39cc3f3 100644 --- a/daemon/daemon.h +++

https://bugzilla.redhat.com/show_bug.cgi?id=1477623 The first two patches are cleanups. The third patch changes the way that we handle Device and Dev_or_Path parameters so that a parameter marked as such can really only contain a block device name (and not, for instance, a chardev). Using a chardev here caused hangs in the API. The next two patches fix API usage to conform to this new stricter

Add a macro STRDUP_RESOLVE_DEVICE_OR_PATH to resolve path or device. Signed-off-by: Wanlong Gao <gaowanlong at cn.fujitsu.com> --- daemon/daemon.h | 16 ++++++++++++++++ daemon/mount.c | 13 ++----------- 2 files changed, 18 insertions(+), 11 deletions(-) diff --git a/daemon/daemon.h b/daemon/daemon.h index 85eec45..f7d0c75 100644 --- a/daemon/daemon.h +++ b/daemon/daemon.h @@ -336,6

Very large but mechanical change to the generator. Rich.

From: "Richard W.M. Jones" <rjones at redhat.com> Callers are supposed to use the availability API to check for functions that may not be available in particular builds of libguestfs. If they don't do this, currently they tend to get obscure error messages, eg: libguestfs: error: zerofree: /dev/vda1: zerofree: No such file or directory This commit changes the error

It is never normally valid to use the mount-local* APIs when you haven't mounted some filesystems in the libguestfs namespace. If you try it, it results in some odd errors. The mount-local-run call is successful, but subsequent operations fail: $ mkdir -p /tmp/mnt $ guestfish -x -N fs mount-local /tmp/mnt : mount-local-run libguestfs: error: lstat: lstat_stub: you must call 'mount'

Exposing file upload logic as suggested in previous patch: https://www.redhat.com/archives/libguestfs/2016-November/msg00109.html Matteo Cafasso (1): daemon: expose upload logic daemon/daemon.h | 3 +++ daemon/upload.c | 70 ++++++++++++++++++++++++++++++++------------------------- 2 files changed, 42 insertions(+), 31 deletions(-) -- 2.10.2

-- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -------------- next part -------------- >From 9beb53ca567147aa2cd03c8e68b11706bc284713 Mon Sep 17

add udev_settle calls to print_partition_table and sgdisk_info_extract_field because the inspect-os calls guestfs_part_get_parttype and guestfs_part_get_gpt_guid for all parition devices found and this causes intermittent with opening block devices that are certainly present yet RESOLVE_DEVICE macro would fail wiht ENOENT. --- daemon/parted.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff

From: "Richard W.M. Jones" <rjones at redhat.com> For stubs of functions that had arguments, code did this: static void mount_stub (XDR *xdr_in) { int r; struct guestfs_mount_args args; if (optargs_bitmask != 0) { //... goto done; } // possibly other tests here memset (&args, 0, sizeof args); [...] done: xdr_free ((xdrproc_t)

v6: - use new test functions - fix yara_detection struct field names - revert yara_load function to initial version With Pino we were exploring the idea of allowing Users to load multiple rule files with subsequent calls to yara_load API. https://www.redhat.com/archives/libguestfs/2016-November/msg00119.html It turns out impractical due to YARA API limitations. It is possible to load multiple

v8: - Ignore returned value in daemon/upload.c - Report serialization errors in lib/yara.c Matteo Cafasso (8): daemon: ignore unused return value in upload function daemon: expose file upload logic appliance: add yara dependency New API: yara_load New API: yara_destroy New API: internal_yara_scan New API: yara_scan yara_scan: added API tests appliance/packagelist.in

Here are a few warning-removal changes for daemon/: >From eea38a1937ccd396603ed899d829d2982755ea4a Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering at redhat.com> Date: Thu, 6 Aug 2009 15:25:03 +0200 Subject: [PATCH 1/4] define ATTRIBUTE_UNUSED * daemon/daemon.h (__attribute__, ATTRIBUTE_UNUSED): Define. --- daemon/daemon.h | 10 ++++++++++ 1 files changed, 10 insertions(+), 0

The warnings in daemon were aggravating and risky for development (too easy to miss new ones) so I spent some time last week and today working on removing them. The first patch gets us down to almost no warnings with the original -Wall setting. That was by far the hardest part. Once I'd done that, I enabled nearly all of gcc's warnings via gnulib's warnings and manywarnings modules