Re: [Qemu-devel] [PATCH] linux-user: Move qemu-binfmt-conf.sh to Debian model

[Alexander Graf]

> Am 27.01.2016 um 20:54 schrieb Peter Maydell <address@hidden>:
> 
>> On 27 January 2016 at 18:45, Michael Tokarev <address@hidden> wrote:
>> 27.01.2016 17:10, Alexander Graf wrote:
>>> and moves that code into our script, maintaining backwards compatibility 
>>> with
>>> its previous calling scheme. The major benefit of this is that now Debian 
>>> can
>>> just do
>>> 
>>>  HOST_ARCH=$DPKG_MAINTSCRIPT_ARCH
>>>  QEMU_BINFMT_SKIP_REGISTRATION=1
>>>  . /path/to/qemu-binfmt-conf.sh
>>> 
>>> and get the exact same binfmt configuration as the upstream script, 
>>> hopefully
>>> ensuring that in the future the upstream version becomes the maintained one.
>> 
>> I don't think it will work in practice, at least before some good thinking :)
>> It was a quick hack to generalize things like this, and as per above it needs
>> some more work (at least to fix the OSABI issue).
>> 
>> But might be it is better than nothing anyway... :)  Provided it is actually
>> useful, -- do you think it is?
> 
> I was wondering if we should move to supplying the binfmt info
> in files of the form used by update-binfmts(8) (which is just a set
> of "key value" lines), plus a minimal script to read them. That
> at least gets the data (which is what distros will want to deal with)
> out of the script (which is mostly of interest to people doing
> local hacking, if at all). I'm guessing that distro-specific
> format registration handling will be easier to do by parsing data
> files than by trying to work with a script.

FWIW the whole update-binfmts thing is a Debian specific invention. Ideally, 
someone should clean up the whole binfmt mess, make it container aware and move 
the registration logic into systemd. Then we could really just provide 
cross-distro data files.

The main reason I quickly assembled this patch was because the qemu version of 
the update script was missing a few architectures. The one I realized that with 
was the ppc64 one ;).

I am not sure what the best option here is. Make the pain grow big enough to 
get a full solution or at least keep Debian and our in-tree script (which is 
all that openSUSE provides) in sync?

Alex