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

[Michael Tokarev]

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