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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list