Re: [PATCH 0/5]: Fix target_core_user userspace restarts (v2)

[Mike Christie <mchristi@redhat.com>]

On 01/14/2018 10:19 PM, Nicholas A. Bellinger wrote:
> On Sat, 2018-01-13 at 12:50 -0600, Mike Christie wrote:
>> On 01/12/2018 10:08 PM, Nicholas A. Bellinger wrote:
>>> On Fri, 2018-01-12 at 16:41 -0600, Mike Christie wrote:
>>>> On 01/12/2018 04:13 PM, Nicholas A. Bellinger wrote:
> 
> <SNIP>
> 
>>>>
>>>> I guess the options were:
>>>>
>>>> 1. This patch that separates this kind of files and tries to make it
>>>> generic.
>>>> 2. Instead of the generic action dir, I could just make a
>>>> target_core_user specific dir.
>>>> 3. I can modify rtslib with a attr file blacklist, and these special
>>>> files can go in it.
>>>>
>>>> I thought #1 or even #2 was nicer, because attrs seemed like they had a
>>>> specific purpose to get/set info about an object.
>>>
>>> If it's purely to avoid block_dev + reset_ring attr write operation upon
>>> rtslib se_device creation, following how pi_prot_format works with
>>> existing tcmu_attrib_attrs[] is an option too.
>>>
>>> That said, I'm not against adding a new se_device->dev_action_group, but
>>> want to make sure these new attributes are really considered private to
>>> tcmu's own user-space, separate what rtslib + friends code ever expects
>>> to poke at..
>>>
>>> Is that the case..?
>>
>> I am not sure I understood the question completely.
>>
>> I can imagine someone creating other apps and wanting to use these files
>> for similar reasons as tcmu-runner. We have seen people that are making
>> their own tcmu daemons/userspace apps and sometimes use rtslib and
>> sometimes do not. Does that answer your question?
>>
> 
> Was just curious if these actions are intended to be driven by tcmu
> user-space code for resetting kernel code to consistent state during
> error handling, or if end-users would be expected to trigger during
> normal operation..?

Users would never need to use them. It is just for the userspace apps to
coordinate their state with the kernel.

> 
> If it's intended to be driven by tcmu user-space consumers, then adding
> a new config_group makes sense.
> 

Ok.

>> I can go either way on the action dir vs attached patch that implements
>> them as attrs. I did know about the 4th pi_prot_format style option :)
> 
> Likewise.  :)
> 
> That said, assuming tcmu-runner & friends will be using these attributes
> internally, I'm OK with merging the original series.
> 

Ok.