[PATCH 18/18] nvmet-tcp: add configfs attribute 'param_keyring'
Sagi Grimberg
sagi at grimberg.me
Mon Apr 17 06:50:50 PDT 2023
>>>>> 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?
More information about the Linux-nvme
mailing list