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. >>> LD_LIBRARY_PATH. >> 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 build/test. > > 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) > 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? > 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. Child qemu instance should just ignore it. Thanks, Laurent
