Re: [libvirt] [PATCH v3 3/4] scsi: Adjust return value for virStorageBackendSCSINewLun
work - so we'll short circuit here.
>>
>> This also rejects the non-stable path '/dev' that was accepted before.
>>
>
> Not quite sure I see the issue - can you be more specific? Am I missing
> something obvious?
>
> Previously if "pool->def->target.path" is "/dev" (or NULL
or "/dev/" or
> didn't start with "/dev"), then we'd return a strdup'd
'devpath' into
> 'vol->target.path'.
>
> I see no way 'devpath' could be '/dev' or '/dev/' since it is
formatted as :
>
> if (virAsprintf(&devpath, "/dev/%s", dev) < 0)
> goto cleanup;
That's the path to the device. The comment above is right about checking
the pool target path in the pool definition.
After this patch, if pool->def->target.path is "/dev", we wouldn't
even
get to the virStorageBackendStablePath call, because of the check in
virStorageBackendPoolUseDevPath - it will return false, we'll jump to
cleanup and skip over this volume.
Hmmm.. maybe I need to think outloud... Assume I change the check to:
if (!virStorageBackendPoolPathIsStable(pool->def->target.path) &&
!(STREQ(pool->def->target.path, "/dev") ||
STREQ(pool->def->target.path, "/dev/"))) {
So, if pool->def->target.path is "/dev", then we'll alloc vol,
formulate
'devpath', then call virStorageBackendStablePath. Then
virStorageBackendPoolPathIsStable is called which returns false because
the pool->def->target.path is "/dev".
That causes us to strdup the incoming "/devpath" and return. Upon
return we'd end up returning -2 to the caller.
So, is this the path you were considering? If not, then please describe
in detail.
As it turns out setting pool->def->target.path to "/dev" or
"/dev/"
doesn't cause us to follow down the path of the virReadDir (could take a
while if it did).
Help turn the lightbulb on!
John