[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 <riku.voi...@iki.fi> 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
