[pve-devel] [PATCH v2 container 1/9] tools: add can_use_new_mount_api helper

[Oguz Bektas]

hi,

On Wed, Nov 13, 2019 at 10:33:11AM +0100, Wolfgang Bumiller wrote:
> Signed-off-by: Wolfgang Bumiller <w.bumiller at proxmox.com>
> ---
> New patch
> 
>  src/PVE/LXC/Tools.pm | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/src/PVE/LXC/Tools.pm b/src/PVE/LXC/Tools.pm
> index bebd7d8..0256b6a 100644
> --- a/src/PVE/LXC/Tools.pm
> +++ b/src/PVE/LXC/Tools.pm
> @@ -2,6 +2,8 @@
>  
>  package PVE::LXC::Tools;
>  
> +use Errno qw(ENOSYS);
> +
>  use PVE::SafeSyslog;
>  
>  # LXC introduced an `lxc.hook.version` property which allows hooks to be executed in different
> @@ -130,4 +132,20 @@ sub cgroup_do_write($$) {
>      return 1;
>  }
>  
> +# Check whether the kernel supports the new mount api. This is used in the pre-start hook and in
> +# the hotplugging code.
> +my $cached_can_use_new_mount_api = undef;
> +sub can_use_new_mount_api() {

i don't like these names.. isn't can_use_new_mount_api() a bit too
vague? "new" is also relative, it won't be "new" in a few releases

maybe something like can_hotplug_mountpoint() would be better,
describing what it checks in a more verbose way?

> +    if (!defined($cached_can_use_new_mount_api)) {
> +	if (PVE::Tools::fsopen(0, 0)) {
> +	    # This should not be possible...
> +	    die "kernel behaved unexpectedly: fsopen(NULL, 0) did not fail!\n";
> +	}
> +	# On older kernels the syscall doesn't exist and we get ENOSYS. (For newer kernels this call
> +	# will fail with EFAULT instead, since we pass in a NULL pointer as file system name.)
> +	$cached_can_use_new_mount_api = ($! != ENOSYS);
> +    }
> +    return $cached_can_use_new_mount_api;
> +}
> +
>  1;
> -- 
> 2.20.1
>