All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Otubo <eduardo.otubo@profitbricks.com>
To: Paul Moore <pmoore@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Philipp Gesang <philipp.gesang@intra2net.com>
Subject: Re: [Qemu-devel] [PATCH] seccomp: change configure to avoid arm 32 to break
Date: Thu, 6 Nov 2014 10:24:41 +0100	[thread overview]
Message-ID: <20141106092440.GA16381@vader> (raw)
In-Reply-To: <2511814.5UZKhYSZ5W@sifl>

On Wed, Nov 05, 2014 at 03:35:09PM -0500, Paul Moore wrote:
> On Wednesday, November 05, 2014 08:08:06 PM Peter Maydell wrote:
> > On 5 November 2014 19:46, Paul Moore <pmoore@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"?

I don't think it's worth to point to a non existing version right now,
it might confuse people.

> 
> I would probably just limit QEMU/seccomp to x86_64 and x86.  Once we have the 
> new release that fixes everything we can start worrying about versions and 
> different ABIs.

That's fine for me, since is a temporary fix. I'll just go and rewrite
this patch, then.

Paul, do you have any plans for a new libseccomp release?

Regards,

-- 
Eduardo Otubo
ProfitBricks GmbH

  reply	other threads:[~2014-11-06  9:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-05 16:47 [Qemu-devel] [PATCH] seccomp: change configure to avoid arm 32 to break Eduardo Otubo
2014-11-05 17:08 ` Peter Maydell
2014-11-05 19:46   ` Paul Moore
2014-11-05 20:08     ` Peter Maydell
2014-11-05 20:35       ` Paul Moore
2014-11-06  9:24         ` Eduardo Otubo [this message]
2014-11-06 16:37           ` Paul Moore
  -- strict thread matches above, loose matches on Subject: below --
2014-11-06 14:49 Eduardo Otubo
2014-11-06 15:49 ` Peter Maydell
2014-11-06 16:22   ` Eduardo Otubo
2014-11-06 16:22 ` Paul Moore
2014-11-06 16:36   ` Eduardo Otubo
2014-11-06 16:54     ` Paul Moore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141106092440.GA16381@vader \
    --to=eduardo.otubo@profitbricks.com \
    --cc=peter.maydell@linaro.org \
    --cc=philipp.gesang@intra2net.com \
    --cc=pmoore@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.