[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