CCing the right Eduardo. :)
On Wed, Apr 03, 2019 at 10:16:15PM +0700, Peter Maydell wrote: > On Wed, 3 Apr 2019 at 19:51, Helge Deller <del...@gmx.de> wrote: > > [cc'ing Eduardo as the seccomp submaintainer] > > > On a non-release architecture, the configure program aborts if the > > --enable-seccomp flag was given (with no way to work around it on the > > command line): > > > > ERROR: User requested feature libseccomp > > configure was not able to find it. > > libseccomp is not supported for host cpu parisc64 > > Surely the workaround is "don't pass --enable-seccomp on > the configure command line" ? > > Our general approach with configure arguments is: > --disable-foo means "don't try to look for or use foo" > --enable-foo means "use foo, and stop with an error if we can't use > foo for any reason (eg not found, version too old)" > passing nothing means "look for foo, use it if we can, > but if we can't then just silently don't use foo" > > So I think if the user specifically asks us to use seccomp on a > host architecture where it won't work then configure should fail. > > Is the underlying problem here: > * we use a whitelist of host architectures to enable seccomp for > and we should not do that (eg blacklist instead, or just allow it > for any host architecture)? > * using a whitelist is ok, but we should add some more host archs to it? > * something else? > > What particular host arch are you using? > > thanks > -- PMM -- Eduardo
