From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: qemu-devel@nongnu.org
Cc: venture@google.com, "Peter Foley" <pefoley@google.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Thomas Huth" <thuth@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Peter Foley" <pefoley@google.com>
Subject: Re: [PATCH] Don't require libcap-ng for virtfs support
Date: Mon, 24 Apr 2023 11:04:47 +0200 [thread overview]
Message-ID: <6278798.ENyYtN1ivr@silver> (raw)
In-Reply-To: <20230421135327.1778365-1-pefoley@google.com>
On Friday, April 21, 2023 3:53:27 PM CEST Peter Foley wrote:
> It's only required for the proxy helper.
>
> Signed-off-by: Peter Foley <pefoley@google.com>
> ---
> meson.build | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/meson.build b/meson.build
> index c44d05a13f..1d4888b1c0 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1759,12 +1759,12 @@ have_virtfs = get_option('virtfs') \
> error_message: 'virtio-9p (virtfs) requires Linux or macOS') \
> .require(targetos == 'linux' or cc.has_function('pthread_fchdir_np'),
> error_message: 'virtio-9p (virtfs) on macOS requires the presence of pthread_fchdir_np') \
> - .require(targetos == 'darwin' or (libattr.found() and libcap_ng.found()),
> - error_message: 'virtio-9p (virtfs) on Linux requires libcap-ng-devel and libattr-devel') \
> + .require(targetos == 'darwin' or libattr.found(),
> + error_message: 'virtio-9p (virtfs) on Linux requires libattr-devel') \
> .disable_auto_if(not have_tools and not have_system) \
> .allowed()
>
> -have_virtfs_proxy_helper = targetos != 'darwin' and have_virtfs and have_tools
> +have_virtfs_proxy_helper = targetos != 'darwin' and have_virtfs and have_tools and libcap_ng.found()
Well, I don't know how many people actually use the 9p proxy, if at all, but
don't you think there should be at least a warning or some kind of output e.g.
in the configure summary that QEMU would build without 9p proxy support just
because of a missing lib, instead of silently disabling it?
For macOS hosts we didn't care so far, because proxy is not implemented there
and probably never will.
>
> if get_option('block_drv_ro_whitelist') == ''
> config_host_data.set('CONFIG_BDRV_RO_WHITELIST', '')
>
next prev parent reply other threads:[~2023-04-24 9:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-21 13:53 [PATCH] Don't require libcap-ng for virtfs support Peter Foley
2023-04-24 9:04 ` Christian Schoenebeck [this message]
2023-04-28 13:34 ` [PATCH v2] " Peter Foley
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=6278798.ENyYtN1ivr@silver \
--to=qemu_oss@crudebyte.com \
--cc=berrange@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=pbonzini@redhat.com \
--cc=pefoley@google.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
--cc=venture@google.com \
/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.