From: Paolo Bonzini <pbonzini@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Joakim Tjernlund <joakim.tjernlund@transmode.se>,
Riku Voipio <riku.voipio@iki.fi>,
Michael Tokarev <mjt@tls.msk.ru>, Alexander Graf <agraf@suse.de>,
QEMU Developers <qemu-devel@nongnu.org>,
Cole Robinson <crobinso@redhat.com>
Subject: Re: [Qemu-devel] linux-user: enabling binfmt P flag
Date: Mon, 01 Sep 2014 11:28:49 +0200 [thread overview]
Message-ID: <54043C51.9010307@redhat.com> (raw)
In-Reply-To: <CAFEAcA-Lb-5rj32d6F1f5zFWBnCKisWwVMbQYkNXf+BFALw2hg@mail.gmail.com>
Il 01/09/2014 11:12, Peter Maydell ha scritto:
>> 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?
Yes, but it's not like Fedora'd have choice. Distros have to follow
what upstream does, even if it breaks something else (or they could
revert the "P" patch and get an entirely specular set of bug reports).
>> > 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.
I think it's simply that "P" was ill-designed (possibly because
implementing the above is not trivial).
Paolo
next prev parent reply other threads:[~2014-09-01 9:29 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-25 9:09 [Qemu-devel] linux-user: enabling binfmt P flag Riku Voipio
2014-08-25 9:14 ` Alexander Graf
2014-08-25 11:10 ` Joakim Tjernlund
2014-08-25 12:42 ` Riku Voipio
2014-08-25 12:46 ` Alexander Graf
2014-08-25 13:18 ` Riku Voipio
2014-08-25 13:20 ` Laurent Vivier
2014-08-25 13:39 ` Joakim Tjernlund
2014-08-25 13:55 ` Riku Voipio
2014-08-25 14:30 ` Joakim Tjernlund
2014-08-25 14:49 ` Riku Voipio
2014-08-25 15:02 ` Joakim Tjernlund
[not found] ` <OF93B0417A.866825C3-ONC1257D3F.005235F4-C1257D3F.0052A534@LocalDomain>
2014-08-28 16:06 ` Joakim Tjernlund
2014-08-29 18:01 ` Peter Maydell
2014-08-30 8:28 ` Joakim Tjernlund
2014-09-01 8:51 ` Paolo Bonzini
2014-09-01 9:12 ` Peter Maydell
2014-09-01 9:28 ` Paolo Bonzini [this message]
2014-09-01 9:32 ` Peter Maydell
2014-09-01 9:51 ` Riku Voipio
2014-09-17 15:34 ` Joakim Tjernlund
2014-09-17 16:12 ` Peter Maydell
2014-09-17 19:25 ` Paolo Bonzini
2014-09-17 19:31 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54043C51.9010307@redhat.com \
--to=pbonzini@redhat.com \
--cc=agraf@suse.de \
--cc=crobinso@redhat.com \
--cc=joakim.tjernlund@transmode.se \
--cc=mjt@tls.msk.ru \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=riku.voipio@iki.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.