[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 22:27:50 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0

On 20/06/16 21:29, Laurent Vivier wrote:

Le 20/06/2016 à 21:51, Joel Holdsworth a écrit :
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.
If the context is to use qemu to have a cross build/test environment, I
like the idea, but you should use chroot/binfmt to do that.

Even without the architecture change, the build/test environment must be
isolated (chroot) from the host environment to know exactly what you
I do know what we test though: (a gstreamer unit test) -> (gst-plugin-scanner).

chroot+binfmt is a fine solution for testing a whole user-space, but rather overkill for just a single program.

Also, chroot and binfmt require root permissions. Also the libraries have to be installed in a rootfs tree - which isn't how my use case works.

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.
You can provide the RPM/DEB with the statically linked qemu.
(it will have no dependencies)

Users could do that, but as far as I'm concerned that isn't really satisfactory.

The current behaviour was quite unexpected to me - there were no warnings, and the need to link qemu statically isn't documented anywhere. If you really believe that static linking is the best answer here, then shouldn't the shared library option be removed? Because with the shared-library build, qemu-user is somewhat "broken".

But the distros won't like that because of the induced bloat.

Moreover, LD_LIBRARY_PATH is just one example. LD_PRELOAD is another.
Timezone and locale environment variables are also an issue.
all LD_ are for the ld.so, the dynamic loader, and with a statically
linked qemu, you don't use the host ld.so (see ld.so(8)).

Why timezone and local environment variables are also an issue?
All these environment variables affect the behaviour of qemu's glibc - these are examples of the the parent-guest being able to modify the behaviour of the child-host if the execve qemu wrapper patch is integrated. The correct way to pass the execve environ to the child qemu wrapper is through -E and -U arguments.

Child qemu instance should just ignore it. Thanks, Laurent

The child qemu can't control what glibc will respond to.

There are a lot of environment variables that can affect it: http://www.scratchbox.org/documentation/general/tutorials/glibcenv.html

For example with LANG=, the parent-guest process might want to run the child-guest in Japanese, but the child-qemu should still run in English.

reply via email to

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