On 5 November 2014 19:46, Paul Moore <pmo...@redhat.com> 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
