Re: [PATCH 1/3] nvmet: expose discovery subsystem in sysfs

[Christoph Hellwig <hch@lst.de>]

On Tue, Mar 15, 2022 at 10:06:26AM +0100, Hannes Reinecke wrote:
> The core question really is: do we _want_ to expose the discovery subsystem 
> in configfs?

Well, if you want a freely configurable one we kinda have to, right?

> Unfortunately, exposing the discovery subsystem and trying to configure it 
> with configfs does _not_ match with the way discovery is implemented today. 
> While we currently only have a single discovery subsystem, it will only 
> ever return the subsystems visible from this particular port.

Well.  The original Fabrics spec had this concept of that magic discovery
NQN, which implies that there is one subsystem (or many pretending to be
one).  And that is what the implementation followed.  The varipus 80?? TPs
then made a complete mess off that.

> Hence this rather simple approach, having the 'normal' discovery subsystem 
> exposed, and let the admin configure it accordingly.
>
> I can look at keeping the internal implementation, and only expose unique 
> discovery controller (ie those with a unique subsystem NQN).
> That would remove the need to having the 'discovery_nqn' attribute, and 
> address Christophs concerns.

I suspect if we want to support all the new mess from the FMDS group
(and maybe we need to question the why a little more), then we should
so something like:

 (1) keep the existing global NQN-based discovery as-is.
 (2) maybe add a per-port known to allow disabling it if people really care
 (3) allow creating additional discovery subsystems with non-default
     NQNs that do not automatically get anything added to them and will
     just be configured as needed through configfs

But maybe first we should take a step back and figure out what supporting
TPAR8013 even buys us?