[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] linux-user: manage binfmt-misc preserve-arg[0] flag

From: Michael Tokarev
Subject: Re: [PATCH] linux-user: manage binfmt-misc preserve-arg[0] flag
Date: Mon, 22 Feb 2021 18:11:52 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1

22.02.2021 18:02, Helge Deller wrote:
On 2/22/21 3:58 PM, Michael Tokarev wrote:
22.02.2021 17:54, John Paul Adrian Glaubitz wrote:

OK, gotcha. Is it supposed to work with systemd-binfmt? It looks like it depends
on the old binfmt-support package.

the qemu 4-line patch does not depend on any particular system, it relies on a
special name of its own argv[0] when registering the binfmt entry.  In order to
utilize it, we create a special-named symlink to qemu-foo and register that one
with the binfmt-misc subsystem, no matter if it is systemd or binfmt-support or
whatever else.

... which is pretty hackish (although it apparently works; I haven't tested 

While it is hackish at first glance, the more I think about it the less hackish 
becomes.  The thing is - we're talking about different behavour of some program 
it sees different argv[0]. We can just as well use the same mechanism to 
support this.

The big question remains:
Is this "hack" just a temporary workaround which should be kept, or
is the support via the kernel-patch from Laurent the long-term and better 

I don't care either way or the other, and I don't see the Laurent's one as 
either. It's a long-term issue where quite some bullets has been spent already 
quite some spears has been broken. I come across a solution which actually 
works and
let others who waited for this issue to be solved to do their work.

At the very least, the one requiring kernel patch does not work on current 
while my version works just fine, and we'll keep it in debian for now since it 
to unbreak quite some other things. If qemu upstream will take another approach 
it is
entirely fine with me (after all that's why I sent an RFC in the first place, - 
to show
another (at least one) possible solution and to hear comments, and to develop 
which is good in the end). Hopefully we'll be able to switch to a better 
solution once
it's settled and will be available within current distributions.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]