[PATCH 18/18] nvmet-tcp: add configfs attribute 'param_keyring'

[Sagi Grimberg]

>>>>>>> Add a configfs attribute to list and change the default keyring.
>>>>>>
>>>>>> is the keyring an attribute of a port? or a subsystem? Why the choice
>>>>>> of making it per port?
>>>>>>
>>>>> As per discussion at fmds each port might want to use different 
>>>>> credentials.
>>>>> We can move it to subsystems if we decide we don't want to support 
>>>>> that use-case.
>>>>
>>>> I think we should move it to the subsystem in Linux.
>>>>
>>> Easier said than done.
>>>
>>> We can only fetch the subsystem once we have the NQN, which we will
>>> know after the connect command.
>>> But out of necessity the connect command will only be transferred
>>> after TLS handshake completed, so there is not subsystem NQN allowing
>>> us to figure out the correct subsystem.
>>>
>>> So we'll have to keep it at the port level, I'm afraid.
>>
>> Question, why does nvmet needs to support user defined keyrings?
>> I understood your argument for the host, but why should the target
>> support it?
> 
> Hmm. Originally I implemented it to be similar to the host 
> configuration, but from the implementation we don't _actually_ need it 
> as we select the key from the entire key store.

Thanks for confirming.

> Having it is just a nice way of avoiding having to have a daemon 
> configuration.

I'm sorry, but I don't understand this statement. Can you clarify?

> So if you insist we can drop it for the initial implementation.

If there is a use-case, we can add it. But I'm trying to understand what
is it.