[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: |
Riku Voipio |
Subject: |
Re: [Qemu-devel] [PATCH v2 2/4] linux-user: pass environment arguments in execve |
Date: |
Mon, 20 Jun 2016 23:08:28 +0300 |
20.6.2016 22.51 Joel Holdsworth <address@hidden>
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.
>
>
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Qemu-devel] [PATCH v2 2/4] linux-user: pass environment arguments in execve,
Riku Voipio <=