[pve-devel] [PATCH v2 storage 01/10] iscsi direct plugin: fix return value for path() method in non-array context
Fiona Ebner
f.ebner at proxmox.com
Wed Dec 18 14:39:12 CET 2024
Am 17.12.24 um 16:48 schrieb Fiona Ebner:
> Signed-off-by: Fiona Ebner <f.ebner at proxmox.com>
> ---
>
> New in v2.
>
> src/PVE/Storage/ISCSIDirectPlugin.pm | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/PVE/Storage/ISCSIDirectPlugin.pm b/src/PVE/Storage/ISCSIDirectPlugin.pm
> index eb329d4..6f02eee 100644
> --- a/src/PVE/Storage/ISCSIDirectPlugin.pm
> +++ b/src/PVE/Storage/ISCSIDirectPlugin.pm
> @@ -100,7 +100,7 @@ sub path {
>
> my $path = "iscsi://$portal/$target/$lun";
>
> - return ($path, $vmid, $vtype);
> + return wantarray ? ($path, $vmid, $vtype) : $path;
> }
>
> sub create_base {
Actually, not sure if this is considered required by the plugin API (and
thus whether to call it a "fix"). The call in Storage.pm is
> my ($path, $owner, $vtype) = $plugin->path($scfg, $volname, $storeid, $snapname);
> return wantarray ? ($path, $owner, $vtype) : $path;
However, there are calls
> my $file = $class->path($scfg, $volname, $storeid)
in the (import/export calls) of the base implementation in Plugin.pm
which can get inherited by other plugins. Either we require the
wantarray detection in the API (technically also requires a APIAGE/VER
bump) or we change these calls not to expect the detection.
IMHO, it seems nicer to have the detection, as it's very easy to end up
with a broken call in scalar context.
More information about the pve-devel
mailing list