>>
>> FWIW: The lock gets easier with RFC series and of course that's in the
>> back of my mind every time I touch this code... All the fun I'll have
>> merging changes...
>>
>
> Ah, which patches are that? I want to review them.
>
> Michal
>
I need to post an update since nodedev and
On 02/27/2017 11:05 PM, John Ferlan wrote:
> [...]
>
>>> Anyway, so as an adjustment at least here... I could move the hunk below
>>> the pool->active = 1 and before the event. Then drop the lock entirely
>>> before call the testCreateVport. Would also need to add a 'isLocked' so
>>> that the
[...]
>> Anyway, so as an adjustment at least here... I could move the hunk below
>> the pool->active = 1 and before the event. Then drop the lock entirely
>> before call the testCreateVport. Would also need to add a 'isLocked' so
>> that the unlock isn't called unnecessarily. Of course that's
On 27.02.2017 17:50, John Ferlan wrote:
>
>
> On 02/27/2017 10:36 AM, Michal Privoznik wrote:
>> On 20.02.2017 14:18, John Ferlan wrote:
>>> Add a new test to fchosttest in order to test creation of our vHBA
>>> via the Storage Pool logic. Unlike the real code, we cannot yet use
>>> the
On 02/27/2017 10:36 AM, Michal Privoznik wrote:
> On 20.02.2017 14:18, John Ferlan wrote:
>> Add a new test to fchosttest in order to test creation of our vHBA
>> via the Storage Pool logic. Unlike the real code, we cannot yet use
>> the virVHBA* API's because they (currently) traverse the file
On 20.02.2017 14:18, John Ferlan wrote:
> Add a new test to fchosttest in order to test creation of our vHBA
> via the Storage Pool logic. Unlike the real code, we cannot yet use
> the virVHBA* API's because they (currently) traverse the file system
> in order to get the parent vport capable
Add a new test to fchosttest in order to test creation of our vHBA
via the Storage Pool logic. Unlike the real code, we cannot yet use
the virVHBA* API's because they (currently) traverse the file system
in order to get the parent vport capable scsi_host. Besides there's
no "real" NPIV device
