[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 2/4] linux-user: pass environment arguments i

From: Joel Holdsworth
Subject: Re: [Qemu-devel] [PATCH v2 2/4] linux-user: pass environment arguments in execve
Date: Mon, 20 Jun 2016 20:51:21 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0

On 15/06/16 20:59, Laurent Vivier wrote:

Le 14/06/2016 à 21:26, Joel Holdsworth a écrit :
Previously, when emulating execve(2), qemu would execute a child
instance of the emulator with the environment variables provided by
the parent process. This caused problems with qemu if any of the
variables affected the child emulator's behaviour e.g.
The best way to avoid that is to use a statically linked qemu.

Stepping back a bit; the problem I'm trying to solve is this...

There are some processes that invoke a helper process to do some work for them e.g. gstreamer's gst-plugin-scanner. Previously qemu would attempt to execute the helper executable as if it were machine-native, which won't work. These patches modify qemu so that it will (optionally) run the child process inside a child instance of qemu.

My experience as a user was that it took a couple of hours of searching through strace logs to figure out what the issue was. gstreamer would just fail with a generic error about the helper. These patches are meant to make qemu do the right thing.

Saying to the user that they should make a static linked build of qemu isn't very practical. Having a command line argument is a much easier solution for the user, that doesn't force them not to used shared-library builds. The distros aren't going to go for that.

Moreover, LD_LIBRARY_PATH is just one example. LD_PRELOAD is another. Timezone and locale environment variables are also an issue.

In an ideal world, it wouldn't even be necessary to add an argument - qemu would just do the right thing automatically. Though I'm not sure how that could be done correctly, so a command line option is a good compromise for a starting point.

This patch solves this issue by passing the environment variables
with '-E' arguments to the child qemu instance. The call to
execve(2) is replaced by a call to execv(2) so that the parent
emulator's environment variable state is propagated into the child.

Any variables from the host environment that are not in the in the
execve() call are removed with a '-U' argument.
Run ./scripts/checkpatch.pl on your patch...

and add your Signed-off-by here.
Sure ok.

The environment is already managed in linux-user/main.c:main(), I don't
understand why the qemu_execve() special case should differ from the
general case.
Maybe I've missed something, but the problem I'm trying to solve here is the issue of correctly propagating the guest environment variables into the child process.

The parent guest process (running inside qemu-user) constructs a set of environment variables and passes them to execve. However, if the parent qemu-user decides to run a child instance of qemu-user it should run with the same environment variables as the parent, but with environment variables the parent-guest passed through the arguments for the child-guest.

If gstreamer decides to run gst-plugin-scanner with a certain environ, that is for the child qemu guest, not the child qemu instance itself.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]