[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] linux-user: enabling binfmt P flag
From: |
Joakim Tjernlund |
Subject: |
Re: [Qemu-devel] linux-user: enabling binfmt P flag |
Date: |
Wed, 17 Sep 2014 17:34:37 +0200 |
Riku Voipio <address@hidden> wrote on 2014/09/01 11:51: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..
Did this go anywhere ? Is there a solution in sight?
Jocke