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

[John Meneghini]

On 4/5/22 07:12, Hannes Reinecke wrote:
> 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.

I don't think we need to change the discovery subsystem.  I think what we want, in the simple case, is 2 discovery subsystems: 
1) the existing well known discovery controller with the well-known discovery NQN, 2) a unique discovery controller with a 
unique discovery NQN.

The first well known discovery controller exists today and doesn't need to be configurable (unless you're going to do something 
stupid like support fabric authenticate with the well known discovery NQN).

The second unique discovery controller can be configured just like any other NVM subsystem, but its discovery log pages show up 
in the well known discovery controller log page with Subsystem Type (SUBTYPE): 03h - as defined by TP-8014.

So the well known discovery controller always returns log page entries for three types of log pages:

NVME_NQN_DISC,	"referral"
NVME_NQN_NVME,	"nvme"
NVME_NQN_CURR,	"discovery"

When there is no unique discovery controller configured the NVME_NQN_CURR log page has no entries and everything works as it 
does today.

When someone configures a unique discovery NQN, the controller is created and all of the NVME_NQN_NVME log page entries move
to the new unique discovery controller while the NVME_NQN_CURR log page entries on the well-known discovery controller report 
only the NVME_NQN_CURR and NVME_NQN_DISC log page entires.

This is one possible approach.

> And, of course, we still end up with a defunct discovery subsystem if we create a unique discovery subsystem.

Why do we have to defunct the discovery subsystem if we create a unique discover 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?

I would say yes. The user has to create the unique discovery controller and assign it a unique NQN

> 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 ...

I don't understand why there needs to be any stale subsystems.  If we add a optional subsystem (the unique discovery controller) 
we don't need to take anything away.

/John

> Cheers,
> 
> Hannes