[PATCH 2/3] nvmet: make the subsystem type configurable

[Hannes Reinecke]

On 4/5/22 12:35, Sagi Grimberg wrote:
> 
>>>> I actually looked into that with my previous attempt, and really 
>>>> found no
>>>> good way of having an entry which is
>>>> a) pre-filled
>>>> and
>>>> b) removable by the admin later on.
>>>>  From what I've seen all pre-filled entries are static; I haven't 
>>>> found a
>>>> way to do pre-filled dynamic entries.
>>>
>>> I don't think we need to remove the well known discovery subsystem. But
>>> we can allow removing all entries from it and thus reporting an empty
>>> log.
>>
>> Hmm.
>> We still would need to pre-fill these entries when creating subsystems.
>> Bringing us back to square one, namely there is no way to create 
>> dynamic pre-filled entries.
> 
> Why do we need to remove it altogether? Why not just make these
> subsystems attach to port(s) like any other subsystem?

That's what I tried in my first attempt, which got rejected as it does 
break existing installations.
We could introduce a module option for this (and I think that's what I 
did in my first round).
And yes, ideally I would like to have the discovery subsystem as a 
'normal' subsystem just like the others; should be trivial to expose the 
current one in configfs.
But then changing the subsystem NQN becomes awkward:
- Either we create a new subsystem with the unique NQN, but then we have 
to change the type later on (as creation happens with a simple 'mkdir', 
and one cannot really pass arguments to that).
- Or we have a distinct discovery subsystem type (ie the idea Christoph 
mentioned), but then we have to cross-check the directory names against 
the existing one in the 'normal' subsystem directory.
And, of course, we still end up with a defunct discovery subsystem if we 
create a unique discovery subsystem.

Alternatively: if we're going to break existing configurations anyway 
(or, rather, have to modify nvmetcli to handle the new discovery 
mechanism), why do we need to start off with a default discovery subsystem?
Can't we require the user to create one?
We would be requiring a module option here, but that looks like the best 
approach here as we won't have to deal with stale subsystems ...

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare at suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer