search for: guestfs_event_appliance

v4: - Lots more analysis of the /init script and other parts. - Display a list of the longest to shortest activities. - Rebase on top of current head. Rich.

...ess_quit_callback, + GUESTFS_EVENT_SUBPROCESS_QUIT, 0, data); + guestfs_set_event_callback (g, launch_done_callback, + GUESTFS_EVENT_LAUNCH_DONE, 0, data); + guestfs_set_event_callback (g, appliance_callback, + GUESTFS_EVENT_APPLIANCE, 0, data); + guestfs_set_event_callback (g, library_callback, + GUESTFS_EVENT_LIBRARY, 0, data); + guestfs_set_event_callback (g, trace_callback, + GUESTFS_EVENT_TRACE, 0, data); + + guestfs_set_verbose (g, 1); + guestfs_set_trace (g, 1)...

Lots of changes since v2, too much to remember or summarize. Please ignore patch 11/11, it's just for my testing. Rich.

...7da31fa 100644 --- a/utils/boot-analysis/boot-analysis-timeline.c +++ b/utils/boot-analysis/boot-analysis-timeline.c @@ -195,7 +195,7 @@ construct_timeline (void) /* Find where we run qemu. */ FIND_OPTIONAL ("qemu", LONG_ACTIVITY, data->events[j].source == GUESTFS_EVENT_APPLIANCE && - strstr (data->events[j].message, "-nodefconfig"), + strstr (data->events[j].message, "-no-user-config"), data->events[k].source == GUESTFS_EVENT_CLOSE); /* For the libvirt backend, connecting to...

v1 was here: https://www.redhat.com/archives/libguestfs/2016-March/thread.html#00157 Not running the 'hwclock' command reduces boot times considerably. However I'm not sure if it is safe. See the question I posted on qemu-devel: http://thread.gmane.org/gmane.comp.emulators.qemu/402194 At the moment, about 50% of the time is consumed by SeaBIOS. Of this, about ⅓rd is SGABIOS

Using the quiet option (when not in verbose mode) improves boot speeds by rather a lot, by avoiding sending messages over the slow emulated UART. Rich.

...the man page. Rich. ---------------------------------------------------------------------- /* Events. */ #define GUESTFS_EVENT_CLOSE 0x0001 #define GUESTFS_EVENT_SUBPROCESS_QUIT 0x0002 #define GUESTFS_EVENT_LAUNCH_DONE 0x0004 #define GUESTFS_EVENT_PROGRESS 0x0008 #define GUESTFS_EVENT_APPLIANCE 0x0010 #define GUESTFS_EVENT_LIBRARY 0x0020 #define GUESTFS_EVENT_TRACE 0x0040 #define GUESTFS_EVENT_ALL UINT64_MAX #ifndef GUESTFS_TYPEDEF_EVENT_CALLBACK #define GUESTFS_TYPEDEF_EVENT_CALLBACK 1 typedef void (*guestfs_event_callback) (...

......" string from kernel output in order to determine part of where we are in the boot process. This string will no longer be detected. We should probably use a BIOS message or maybe drop this altogether. I have added a comment to the code. (2) It is possible for programs to be listening for GUESTFS_EVENT_APPLIANCE events, and they will see fewer messages now (although what kernel messages programs see is never defined). --- src/launch.c | 4 ++-- src/proto.c | 3 +++ 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/src/launch.c b/src/launch.c index 958d4b3..074ac6f 100644 --- a/src/launch.c +...

...nts.c index f707e0b..9a1ca76 100644 --- a/src/events.c +++ b/src/events.c @@ -120,8 +120,7 @@ guestfs___call_callbacks_message (guestfs_h *g, uint64_t event, event == GUESTFS_EVENT_TRACE) && (g->verbose || event == GUESTFS_EVENT_TRACE)) { int from_appliance = event == GUESTFS_EVENT_APPLIANCE; - size_t i; - char c; + size_t i, i0; /* APPLIANCE => <buf> * LIBRARY => libguestfs: <buf>\n @@ -147,13 +146,23 @@ guestfs___call_callbacks_message (guestfs_h *g, uint64_t event, * Case 2: Messages from other sources: These messages should NOT...

This is very useful for debugging multithreaded programs. Rich.

Depends on the previous 5 patches that modified virt-rescue to work without direct mode: https://www.redhat.com/archives/libguestfs/2017-March/msg00017.html Rich.

I've been taking a long hard look at the protocol layer. It has evolved over a long time without any particular direction, and the result is, to say the least, not very organized. These patches take a first step at cleaning up the mess by abstracting out socket operations from the rest of the code. The purpose of this is to allow us to slot in a different connection layer under the

...loads. */ void @@ -295,9 +318,11 @@ void guestfs_set_log_message_callback (guestfs_h *g, guestfs_log_message_cb cb, void *opaque) { + ACQUIRE_LOCK (g); replace_old_style_event_callback (g, log_message_callback_wrapper, GUESTFS_EVENT_APPLIANCE, opaque, cb); + RELEASE_LOCK (g); } static void @@ -317,9 +342,11 @@ void guestfs_set_subprocess_quit_callback (guestfs_h *g, guestfs_subprocess_quit_cb cb, void *opaque) { + ACQUIRE_LOCK (g); replace_old_style_e...

This supersedes the two previous patch series: https://www.redhat.com/archives/libguestfs/2017-March/msg00017.html https://www.redhat.com/archives/libguestfs/2017-March/msg00046.html Rich.

Add some warnings. Well, the first patch is a miscellaneous change, but patches 2-5 add some warnings. Rich.

Version 3: - Tidies up the code further. - Implements correct handling of SIGTSTP and SIGCONT. - Adds: ^] s - sync filesystems - Adds: ^] z - suspend virt-rescue Rich.

This set of patches fixes virt-rescue rather cleanly. In particular the problems with handling ^C are completely fixed. Work still to be done before this can go upstream: - Shutdown doesn't work properly if you exit the shell. At the moment to exit you must do 'reboot -f'. Future improvements: - An escape sequence and escape commands that could be handled by virt-rescue,

This fixes the main issues in virt-rescue and is usable. There are some enhancements which could be made (in follow up work): - An escape sequence and escape commands that could be handled by virt-rescue, eg. to shut down the appliance, mount or unmount filesystems. - `virt-rescue -i' could be implemented cleanly by performing the right API calls before handing control to the

Commits 3c27f3d91e1566854747bbe844186783fc84f3a8 and 1b6f0daa9ae7fcc94e389232d0c397816cda973d added an internal API for running commands asynchronously. It is only used by the copy-in and copy-out APIs. Unfortunately this made the command code very complex: it was almost impossible to redirect stderr to a file, and there were a lot of long-range dependencies through the file. It was also buggy:

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).