similar to: [PATCH] Add safe wrapper around waitpid which deals with EINTR correctly.

Thanks: Eric Blake. --- src/Makefile.am | 1 + src/command.c | 7 ++---- src/guestfs-internal.h | 4 +++ src/launch-direct.c | 11 +++------ src/launch-uml.c | 11 +++------ src/umask.c | 10 ++------ src/wait.c | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++ 7 files changed, 84 insertions(+), 27 deletions(-) create mode 100644

As the start of work to add remote support, I'm taking a close look at the protocol layer in the library. These are some small cleanups. Rich.

v1 was here: https://www.redhat.com/archives/libguestfs/2013-August/msg00005.html This now works, to some extent. The main problem now is that devices are named /dev/ubd[a-] which of course confuses everything. I'm thinking it may be easier to add a udev rule to rename them. Rich.

This is a User-Mode Linux backend for libguestfs. You can select it by doing: export LIBGUESTFS_BACKEND=uml export LIBGUESTFS_QEMU=/path/to/vmlinux Note we're reusing the 'qemu' variable in the handle for convenience. QEmu is not involved when using the UML backend. This almost works. UML itself crashes when the daemon tries to connect to the serial port. I suspect it's

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

https://bugzilla.redhat.com/show_bug.cgi?id=769680

v1 -> v2: - Rebase on top of Pino's version work. Two patches went upstream, these are the two remaining patches. Note the generation number is still inside the qemu.stat file. We could put it in the filename, I have no particular preference. Rich.

On Thu, Apr 14, 2016 at 07:38:23AM -0600, Eric Blake wrote: > > + /* Read the umask. */ > > + if (read (fd[0], &mask, sizeof mask) != sizeof mask) { > > + perrorf (g, "read"); > > + close (fd[0]); > > + return -1; > > Oops - this strands a child process. You have to reap the child, even > if the read() failed. Bleah that was

Inspired by libvirt's virCommand* internal mini-library, this adds some internal APIs for running commands. The first patch contains the new APIs. The subsequent patches change various parts of the library over to use it. Rich.

Doing qemu feature detection in the direct backend takes ~100ms because we need to run `qemu -help' and `qemu -devices ?', and each of those interacts with glibc's very slow link loader. Fixing the link loader is really hard. Instead memoize the output of those two commands. This patch series first separates all the code dealing with qemu into a separate module (src/qemu.c) and

Error out early if the path to the socket will not fit into sockaddr_un::sun_path, as we will not be able to connect to it. --- src/launch-unix.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/launch-unix.c b/src/launch-unix.c index 740c554..973e14b 100644 --- a/src/launch-unix.c +++ b/src/launch-unix.c @@ -47,6 +47,12 @@ launch_unix (guestfs_h *g, void *datav, const char

https://bugzilla.redhat.com/show_bug.cgi?id=836710 https://bugzilla.redhat.com/show_bug.cgi?id=836913 There are at least two related bugs going on: (1) Linux sync(2) system call doesn't send a write barrier to the disk, so in effect it doesn't force the hard disk to flush its cache. libguestfs used sync(2) to force changes to disk. We didn't expect that qemu was caching anything

On Thu, Apr 14, 2016 at 08:04:39AM -0600, Eric Blake wrote: > On 04/14/2016 07:57 AM, Richard W.M. Jones wrote: > > On Thu, Apr 14, 2016 at 07:38:23AM -0600, Eric Blake wrote: > >>> + /* Read the umask. */ > >>> + if (read (fd[0], &mask, sizeof mask) != sizeof mask) { > >>> + perrorf (g, "read"); > >>> + close (fd[0]);

The current implementation of getumask involves writing a file with mode 0777 and then testing what mode was created by the kernel. This doesn't work properly if the user set a per-mount umask (or fmask/ dmask). This alternative method was suggested by Josh Stone. By forking, we can use the thread-unsafe method (calling umask) and pass the result back over a pipe. This change also fixes

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:

The current implementation of getumask involves writing a file with mode 0777 and then testing what mode was created by the kernel. This doesn't work properly if the user set a per-mount umask (or fmask/ dmask). This alternative method was suggested by Josh Stone. By forking, we can use the thread-unsafe method (calling umask) and pass the result back over a pipe. This change also fixes

Hi, I attached the changes I made to a vanilla libguestfs-1.22.6 in order to make it work in mingw/win32. Added is also the patch required to make QEMU compatible (add a command to QMP that lists the supported devices (the regilat way you do it print it to stderr, which is difficult to redirect in win32)). This is done on behalf of Intel Corp. Thanks, Or (oberon in irc)

Since v1: - Base64 decode the Ceph secret before passing it to libvirt. - Don't call virSecretFree (NULL) [libvirt bug?] - Small cleanups.

These three patches (for discussion only, NOT to be applied) implement a mutex system that lets the user limit the number of libguestfs instances that can be launched per host. There are two uses that I have identified for this: firstly so we can enable parallel-tests (the default in automake >= 1.13) without blowing up the host. Secondly oVirt has raised concerns about how to limit the

This attempts to implement the idea proposed in https://www.redhat.com/archives/libguestfs/2010-April/msg00087.html The idea is that an externally managed QEMU (manual, or via libvirt) can boot the appliance kernel/initrd. libguestfs can then be just told of the UNIX domain socket associated with the guest daemon. An example based on guestfish. 1. Step one, find the appliance kernel/initrd