Alexander Graf <ag...@suse.de> 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
