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: Peter Maydell
Subject: Re: [Qemu-devel] linux-user: enabling binfmt P flag
Date: Fri, 29 Aug 2014 19:01:12 +0100

[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?]

On 25 August 2014 10:09, Riku Voipio <address@hidden> wrote:
> After weekend, I think the solution to using the P flag is to
> go back to Joakim's original patch:
>
> http://lists.gnu.org/archive/html/qemu-devel/2014-07/msg02269.html
>
> With this, we get:
>
> If you continue to use qemu-x-static in your binfmt_misc registration,
> nothing changes - both old and new qemu work using the old binfmt
> registration.
>
> If you rename the binary qemu-x-binfmt, you need to update the
> binfmt_misc register to have P flag and new binary  - you get correct
> argv with new qemu. Any old qemu you still have around, will stop
> working. But with "file not found" error rather than obscurely eating
> one of the arguments and running regardless.
>
> This leaves us with one case - people who are used to running
> qemu-x-static ./binary to test single binaries. Distro's will need
> leave a symlink from qemu-x-binfmt qemu-x-static. The "-binfmt" string
> check doesn't trigger, and qemu works as before.
>
> The key point: this way nobody's working setup will break, unless they
> update binfmt registration. As long as the change is done by users
> them self (I need correct argv0 -> I will update binfmt), there is very
> little surprise for anyone.
>
> There will be some fallout once *distributions* change the binfmt - users
> will notice their existing qemu chroots stop working with a "file not
> found" error for any binary they try to run.
>
> If we find even this breakage too much, I'm not sure this can be fixed.

My take on this:
 * I agree we can't break existing working setups with binfmt
registered with "O"
 * It would be nice to have a forward path to binfmt registered
with "OP"
 * The best we can do is provide a QEMU which can work in
both "O" and "OP" configurations, and clearly advertise to
distros and individual users that (a) we recommend the "OP"
config and binary name (b) updating the binfmt config will
break any old QEMU binaries they have lying around in
chroots (c) they should probably provide both binary names
for back-compatibility

ie essentially leave it up to distros whether they want to
move forward to the bright new "correct argv0" future at
the cost of some transition pain, or if they'll just sit with
their current config.

What I really would like is a way for the kernel to tell the
interpreter binary what particular mangling it's chosen to do
of the command line arguments. Then we could have one
binary that coped in both situations and when run via the
command line, and it would just come down to "recommend
OP and tell people/distros to make sure to update the
QEMU binaries in any chroots they have when they make
that change". Unfortunately the kernel doesn't
do that and it would need a kernel change to fix it :-(

-- PMM



reply via email to

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