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: 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




reply via email to

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