[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] linux-user: enabling binfmt P flag
From: |
Riku Voipio |
Subject: |
Re: [Qemu-devel] linux-user: enabling binfmt P flag |
Date: |
Mon, 1 Sep 2014 12:51:15 +0300 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Mon, Sep 01, 2014 at 10:12:18AM +0100, Peter Maydell wrote:
> 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.
Or people with chroots from older/different distros, already
having a qemu-static inside.
> This is one reason I like the "one binary name for O and
> one for P" approach.
Maybe the new binary name could be something more generic than qemu-x-binfmt.
Say qemu-x-user. Then distributions and users can drop the old binary
name over time, and we are back to one binary again eventually.
> > 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.
There is AT_FLAGS, that seems unused atm (only ever set to 0).
http://lxr.free-electrons.com/source/fs/binfmt_elf.c#L240
As indeed I afree with Paolo that (in hindsight) it was misdesign for the
kernel to tell the application how it invoked us..
Riku
Riku