qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] linux-user: enabling binfmt P flag


From: Peter Maydell
Subject: Re: [Qemu-devel] linux-user: enabling binfmt P flag
Date: Mon, 1 Sep 2014 10:12:18 +0100

On 1 September 2014 09:51, Paolo Bonzini <address@hidden> wrote:
> Il 29/08/2014 20:01, Peter Maydell ha scritto:
>> [cc'ing MJT for more distro opinion since I think fundamentally
>> the choice we ought to make upstream is "what's not going to
>> screw over distros"... Paolo, is there a RedHat QEMU maintainer
>> who would have an opinion here?]
>
> There's Cole Robinson.
>
> BTW, Fedora doesn't use the binfmt scripts from QEMU

That's ok, nobody with any sense doesn't.

>, but does reuse the
> binfmt lines.  We'd just add Ps and we'd be fine.

But this would break all your existing users' existing
chroot setups. That's the question I'm after an answer to:
what do you (as a distro) think would be acceptable as
transitional breakage, if anything?

> However, the problem is not really for distros.  Packagers just read the
> release notes and adjust whatever needs to be adjusted.  The problem is
> for people who compile from source and are bit by conflicting binfmt
> formats from their distro.

This is one reason I like the "one binary name for O and
one for P" approach.

> The solution could be to extend binfmt_misc so that it sets two
> environment variables BINFMT_MISC_PID and BINFMT_MISC_ORIG_ARGV0.  The
> former is set to the pid of the binfmt "interpreter" program, the latter
> to the argv[0] value.  Then QEMU can check if BINFMT_MISC_PID matches
> getpid() and, if so, trust the BINFMT_MISC_ORIG_ARGV0 value.

Certainly if we're in a position to get the kernel to be more
informative about how it invoked us that would be the ideal.

thanks
-- PMM



reply via email to

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