[libvirt] [PATCH v3 3/4] scsi: Adjust return value for virStorageBackendSCSINewLun

[John Ferlan]

 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