qemu-devel
[Top][All Lists]
Advanced

[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: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v2 2/4] linux-user: pass environment arguments in execve
Date: Mon, 20 Jun 2016 23:54:55 +0100

On 20 June 2016 at 23:15, Joel Holdsworth
<address@hidden> wrote:
> Even so, there is still the issue of the other glibc environment variables -
> see my LANG= example of the parent-guest wanting to run a child-guest
> Japanese, but the child-qemu should still run in English.

That particular example is easy in that I don't think qemu
user-mode cares about LANG at all :-)

Needing to be root to set up a chroot is genuinely awkward,
though. proot (https://github.com/proot-me/PRoot) is one
approach to that which uses and wraps around a stock QEMU
to do many of the things you'd need a chroot for without
requiring root to set it up. (it uses the ptrace API to
intercept various syscalls and fix up paths, etc.)

Mostly I think the set of possible solutions QEMU has to
"run a guest binary" are the way they are for historical
reasons:
 * we have "-L sysroot" which works for simple cases where
   you have the dynamic libraries to hand, but which has
   some bad failure modes if the directory tree you point
   it at is large or has symlinks (including QEMU just
   going into an infinite loop at startup)
 * the chroot approach is the most flexible, and handily
   doesn't need much support in QEMU at all, but needing
   root support to set it up is a pain
and this hasn't much changed in many years.

I think my main concern is that if we add a third model of
how usermode works (or extend one of the existing ones)
that we do it with a clear idea of where we're going with that,
rather than adding bits and pieces ad-hoc. [I haven't read the
rest of this patchset, so this isn't a specific comment
on it, just a general observation.]

We could certainly stand to document things better too.

thanks
-- PMM



reply via email to

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