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

[Riku Voipio <riku.voipio@iki.fi>]

On Mon, Sep 01, 2014 at 10:12:18AM +0100, Peter Maydell wrote:
> On 1 September 2014 09:51, Paolo Bonzini <pbonzini@redhat.com> 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