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

[Hannes Reinecke]

On 4/17/23 15:50, Sagi Grimberg wrote:
> 
>>>>>> 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.
Having it is just a nice way of avoiding having to have a daemon 
configuration.
So if you insist we can drop it for the initial implementation.

Cheers,

Hannes