[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] configure: add option for virtiofsd
From: |
Paolo Bonzini |
Subject: |
Re: [PATCH] configure: add option for virtiofsd |
Date: |
Thu, 8 Oct 2020 12:43:54 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 |
On 08/10/20 11:17, misono.tomohiro@fujitsu.com wrote:
> Hi Paolo
>
> Thanks a lot for the clear explanation. I will update the patch to follow the
> meson style.
> I realized virtiofsd actually needs tools (i.e. "--disable-tools
> --enable-virtiofsd"
> does not work with above meson.build) since virtiofsd requires libvhost_user
> which will
> be built ony when tools are built. So, I will keep the current dependency
> check (except 'have_system').
I'm thinking the behavior for --disable-tools --enable-virtiofsd would
be confusing. Therefore, another possibility is not introducing
--enable-virtiofsd. Instead, you can reuse --enable-vhost-user-fs:
- --enable-vhost-user-fs will fail if tools are enabled and cap-ng or
seccomp are unavailable
- --enable-vhost-user-fs --disable-tools will not look for cap-ng or
seccomp, because then the flag only controls inclusion of vhost-user-fs
in the emulators
- if "--enable-vhost-user-fs" is not specified and tools are enabled,
vhost-user-fs will only be included in the emulators if cap-ng and
seccomp are available
- if "--enable-vhost-user-fs" is not specified, tools are enabled and
cap-ng/seccomp are unavilable, vhost-user-fs will not be included in the
emulators either
- if "--enable-vhost-user-fs" is not specified but tools are not
enabled, configure will not check if cap-ng or seccomp.
In this case reusing most of your previous patch, and not moving
everything to meson, is totally okay. I don't want you to impose more
transition work.
Paolo