From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55417) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X6iSP-00030P-W3 for qemu-devel@nongnu.org; Mon, 14 Jul 2014 11:46:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X6iSK-0000ML-Vp for qemu-devel@nongnu.org; Mon, 14 Jul 2014 11:46:25 -0400 Received: from cantor2.suse.de ([195.135.220.15]:44636 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X6iSK-0000M9-Kj for qemu-devel@nongnu.org; Mon, 14 Jul 2014 11:46:20 -0400 Message-ID: <53C3FB4A.3050007@suse.de> Date: Mon, 14 Jul 2014 17:46:18 +0200 From: Alexander Graf MIME-Version: 1.0 References: <1405348708-13909-1-git-send-email-Joakim.Tjernlund@transmode.se> <53C3F57D.4080509@suse.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] linux-user: Add binfmt wrapper List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Joakim Tjernlund Cc: riku.voipio@iki.fi, qemu-devel@nongnu.org On 14.07.14 17:38, Joakim Tjernlund wrote: > Alexander Graf wrote on 2014/07/14 17:21:33: > >> From: Alexander Graf >> To: Joakim Tjernlund , >> Cc: qemu-devel@nongnu.org >> Date: 2014/07/14 17:21 >> Subject: Re: [PATCH] linux-user: Add binfmt wrapper >> >> >> On 14.07.14 16:38, Joakim Tjernlund wrote: >>> The popular binfmt-wrapper patch adds an additional >>> executable which mangle argv suitable for binfmt flag P. >>> In a chroot you need the both (statically linked) qemu-$arch >>> and qemu-$arch-binfmt-wrapper. This is sub optimal and a >>> better approach is to recognize the -binfmt-wrapper extension >>> within linux-user(qemu-$arch) and mangle argv there. >>> This just produces on executable which can be either copied to >>> the chroot or bind mounted with the appropriate -binfmt-wrapper >>> suffix. >>> >>> Signed-off-by: Joakim Tjernlund >> Please make sure to CC Riku on patches like this - he is the linux-user >> maintainer. > Doesn't he read the devel list? Anyhow CC:ed He may or may not. Qemu-devel can be pretty high volume :). > >>> --- >>> linux-user/main.c | 13 +++++++++++++ >>> 1 file changed, 13 insertions(+) >>> >>> diff --git a/linux-user/main.c b/linux-user/main.c >>> index 71a33c7..212067a 100644 >>> --- a/linux-user/main.c >>> +++ b/linux-user/main.c >>> @@ -3828,6 +3828,19 @@ int main(int argc, char **argv, char **envp) >>> int i; >>> int ret; >>> int execfd; >>> + char *binfmt; >>> + >>> + i = strlen( argv[0] ) - strlen ( "-binfmt-wrapper" ); >> The spaces are odd. Did this patch pass checkpatch.pl? Same comment goes >> for almost all function invocations. > ehh, didn't run it through checkpatch.pl. Easy to fix next time. > >>> + binfmt = argv[0] + i; >>> + if (i > 0 && strcmp ( binfmt, "-binfmt-wrapper" ) == 0) { >> This magic needs to be documented somewhere. In fact, I find it pretty >> hard to use in real world scenarios. Imagine a distribution - should it >> package every target binary twice? Should it create hardlinks all over? > How does dists. handle your original binfmt-wrapper? This is not much > different I think. Here you got a choice to create a hardlink or a copy. > Any chroot will only have to bind mount binfmt-wrapper into the chroot or > lxc container. Yeah, and there are reasons my original approach isn't upstream :). > >> I think we should try and find better magic :). Looking at the >> binfmt_misc loading code, I think we can cheat a bit. If we pass the 'O' >> flag (open target binary for handler), binfmt_misc will tell us the >> binary fd in AT_EXECFD: >> >> NEW_AUX_ENT(AT_EXECFD, bprm->interp_data); >> >> We could then use this as a hint that we were spawned by binfmt_misc >> rather than directly and interpret the first argv as target_argv[0]. >> >> Then we can also add the P and O flags to scripts/qemu-binfmt-conf.sh >> and have a solution that works well for everyone. > What to do with P only then? Seems like most dists uses only P If a distro uses the P flag it's not using upstream code, so they have to deal with their own breakage :). Fortunately the binfmt install scripts are usually part of a package too, so they can be updated easily. If a distro cares a lot about backwards compatibility with their old name space, they can still compile the old -binfmt wrapper code and ship it. Alex