qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] seccomp: change configure to avoid arm 32 to br


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] seccomp: change configure to avoid arm 32 to break
Date: Wed, 5 Nov 2014 20:08:06 +0000

On 5 November 2014 19:46, Paul Moore <address@hidden> wrote:
> On Wednesday, November 05, 2014 05:08:20 PM Peter Maydell wrote:
>> On 5 November 2014 16:47, Eduardo Otubo wrote:
>> > Right now seccomp is breaking the compilation of Qemu on armv7l due
>> > to libsecomp current lack of support for this arch. This problem is
>> > already fixed on libseccomp upstream but no release date for that is
>> > scheduled to far. This patch disables support for seccomp on armv7l
>> > temporarily until libseccomp does a new release. Then I'll remove the
>> > hack and update libseccomp dependency on configure script.
>> >
>> > Related bug: https://bugs.launchpad.net/qemu/+bug/1363641
>
> ...
>
>> (How are upstream proposing to fix this anyway? I couldn't
>> figure that out from the mailing list thread.)
>
> The problem was that the released version of libseccomp has some "holes" in
> the internal syscall table for 32-bit ARM with respect to all of the other
> supported architectures.  The current libseccomp upstream has some additional
> tooling and checks to ensure that the different ABI syscall tables are kept in
> sync to prevent something like this from happening in the future.

OK. So should we make QEMU say "if x86_64 or i386, require
seccomp 2.1 or better, else require 2.2 or better" ? If our
current source will build with seccomp 2.2 then that seems like a better
check to put in our configure script than a simple disabling of
the functionality on ARM hosts; it means that if distros end up
with QEMU 2.2 plus seccomp 2.2 the functionality won't be
unnecessarily disabled. (Please correct me if I have your
next-release numbering wrong!)

> I'm more than happy to discuss how libseccomp handles the different
> architectures, but that's probably a bit off-topic for this thread.

I guess the only thing that matters for us is that there wasn't
an API break required for the fix.

thanks
-- PMM



reply via email to

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