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: Mon, 25 Aug 2014 13:10:59 +0200

Alexander Graf <address@hidden> wrote on 2014/08/25 11:14:58:
> 
> On 25.08.14 11:09, Riku Voipio wrote:
> > Hi,
> > 
> > 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.
> 
> I would very much prefer if we could stick with only a single binary.
> And yes, switching semantics when you use binfmt wrappers will hurt for
> a short while, but after that everyone will have their setups changed
> and we're safe for the future.

Yes, but as this is going to break something whatever we do I feel it is 
better
move towards always requiring P flag as this how binfmt should have been 
impl.
from the beginning and have users switch over now.
Then ask the kernel folks for a way to explicitly see what flags are used
from within linux-user so you can adapt automatically.

 Jocke 



reply via email to

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