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

[Michael Tokarev <mjt@tls.msk.ru>]

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 myself).

While it is hackish at first glance, the more I think about it the less hackish it
becomes.  The thing is - we're talking about different behavour of some program when
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 solution?

I don't care either way or the other, and I don't see the Laurent's one as better,
either. It's a long-term issue where quite some bullets has been spent already and
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 distributions,
while my version works just fine, and we'll keep it in debian for now since it allows
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 something
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.

Thanks,

/mjt