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

[Alexander Graf <agraf@suse.de>]

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.

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


Alex