From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53298) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XLuCm-0004K9-Cd for qemu-devel@nongnu.org; Mon, 25 Aug 2014 09:21:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XLuCh-0001ro-Pr for qemu-devel@nongnu.org; Mon, 25 Aug 2014 09:21:04 -0400 Received: from mout.kundenserver.de ([212.227.126.187]:59336) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XLuCh-0001rN-FU for qemu-devel@nongnu.org; Mon, 25 Aug 2014 09:20:59 -0400 Date: Mon, 25 Aug 2014 15:20:49 +0200 (CEST) From: Laurent Vivier Message-ID: <1532202454.109026.1408972849226.open-xchange@oxbaltgw40.schlund.de> In-Reply-To: <53FB301D.9010008@suse.de> References: <20140825090917.GA14835@afflict.kos.to> <53FAFE92.9040001@suse.de> <20140825124257.GA16926@afflict.kos.to> <53FB301D.9010008@suse.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_109025_426819062.1408972849156" Subject: Re: [Qemu-devel] linux-user: enabling binfmt P flag Reply-To: Laurent Vivier List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Riku Voipio , Alexander Graf Cc: peter.maydell@linaro.org, qemu-devel@nongnu.org, joakim.tjernlund@transmode.se ------=_Part_109025_426819062.1408972849156 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Le 25 ao=C3=BBt 2014 =C3=A0 14:46, Alexander Graf a =C3= =A9crit : > > > > > 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" strin= g > >>> check doesn't trigger, and qemu works as before. > >>> > >>> The key point: this way nobody's working setup will break, unless the= y > >>> update binfmt registration. As long as the change is done by users > >>> them self (I need correct argv0 -> I will update binfmt), there is ve= ry > >>> little surprise for anyone. > >>> > >>> There will be some fallout once *distributions* change the binfmt - u= sers > >>> 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 fixe= d. > > > >> 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 fo= r > >> 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 d= ebug > > 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 ;). You can also add the feature and let's the configure manages if it must be enabled or not. Regards, Laurent ------=_Part_109025_426819062.1408972849156 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

> Le 25 août 2014 à 14:46, Alexander Graf <agraf@suse.de> a écrit :
>
>
>
>
> 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 ;).

You can also add the feature and let's the configure manages if it must be enabled or not.
 
Regards,
Laurent
------=_Part_109025_426819062.1408972849156--