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

[Riku Voipio]

On Mon, Aug 25, 2014 at 02:46:21PM +0200, Alexander Graf wrote:
> 
> 
> On 25.08.14 14:42, Riku Voipio wrote:
> > On Mon, Aug 25, 2014 at 11:14:58AM +0200, Alexander Graf wrote:
> >>
> >>
> >> 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.
> >  
> > I don't really the unpredictable nature of the breakage. Take 
> > $ rm a b c
> > 
> > With P flag:    /bin/rm rm a b c
> > Without P flag: /bin/rm a b c
> > 
> > If we use old qemu with P flag: qemu will run /bin/rm with argv: "/bin/rm 
> > rm a b c"
> >  -> tries to delete "rm"
> > If we use new qemu without P flag, qemu will run /bin/rm with argv: "a b c" 
> >  -> fails to delete "a"
> > 
> > This is the black magic errors that drive users nuts when they try to debug 
> > what
> > is happening... "File not found" when the qemu binary is not in the
> > right place is confusing enough.
 
> Yes, but is anyone actually using the "P" flag? We've never advertised
> anywhere that QEMU supports it.

No, we don't use the P flag now. The changeset has not been merged in.
With "new Qemu" I meant Joakims "if O assume P" patch. 

> Maybe we should just make the next version be 3.0 and declare it a major
> ABI breakage ;).
> 
> 
> Alex