From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41517) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF5V6-0002Pq-Ta for qemu-devel@nongnu.org; Mon, 20 Jun 2016 16:08:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bF5V1-0001xd-TS for qemu-devel@nongnu.org; Mon, 20 Jun 2016 16:08:52 -0400 Received: from jessie.kos.to ([212.47.231.226]:59688 helo=pilvi.kos.to) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF5V1-0001uQ-Iy for qemu-devel@nongnu.org; Mon, 20 Jun 2016 16:08:47 -0400 Date: Mon, 20 Jun 2016 23:08:28 +0300 From: Riku Voipio Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: Re: [Qemu-devel] [PATCH v2 2/4] linux-user: pass environment arguments in execve List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Joel Holdsworth Cc: Vasileios.Kalintiris@imgtec.com, Riku Voipio , qemu-devel@nongnu.org, Laurent Vivier 20.6.2016 22.51 Joel Holdsworth kirjoitti: > > On 15/06/16 20:59, Laurent Vivier wrote: > > > > Le 14/06/2016 `a 21:26, Joel Holdsworth a ecrit : > >> 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. > > 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. Actually at least Debian and Ubuntu already ship static qemu-user binaries. Using static qemu-user and binfmt_misc is the standard way people use qemu-user. > > 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. > >