qemu-devel
[Top][All Lists]
Advanced

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

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


From: Michael Tokarev
Subject: Re: [Qemu-devel] [PATCH] linux-user: Move qemu-binfmt-conf.sh to Debian model
Date: Wed, 27 Jan 2016 21:45:59 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0

27.01.2016 17:10, Alexander Graf wrote:
> The qemu-binfmt-conf.sh script has been pretty unmaintained for most of its
> time. The reason is simply that few distributions actually use the file as
> is.

Heh.  I always tried to follow qemu-binfmt-conf.sh in our debian work :)
Granted, later I checked linux-user/main.c (IIRC), too.

> This patch takes the Debian approach to registering binfmt handlers:
> 
>   https://packages.debian.org/en/sid/qemu-user-binfmt

I had a plan to generalize this before next centurity.  The thing is that most
of the formats and masks are the same, the difference is in the endianness,
word size and the architecture.  It might be easier to generate the masks
from the tuples, putting thme 3 fields into places and keepin the rest
the same.  But I haven't got to doing that, so far... :)

See also the fat comment about SYSV vs GNU/LINUX OSABI which needs to
be fixed -- after switching to tuples from masks it will be easier.

> 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?

Thanks,

/mjt



reply via email to

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