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

[Hannes Reinecke]

On 3/15/22 09:40, Sagi Grimberg wrote:
> 
>>> Expose the discovery subsystem in sysfs instead of having it as
>>> an internal structure. This requires the admin to manually
>>> enable the discovery subsystem by linking it to a port, but
>>> this can be seen as a feature as it will allows us to expose
>>> subsystems without discovery subsystems and discovery subsystems
>>> with no I/O subsystems.
>>
>> ... and completely breaks any existing setup.
> 
> Yes, this needs to be backward compatible...

The core question really is: do we _want_ to expose the discovery 
subsystem in configfs?
(And this was actually why I prefixed this series with 'RFC').

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.
(So really, it's more like a discovery subsystem per port.)
When using configfs we can link ports to the subsystem, but seeing that 
we'll only ever have _one_ discovery subsystem we cannot restrict the 
discovery log page contents to that specific port.

Hence this rather simple approach, having the 'normal' discovery 
subsystem exposed, and let the admin configure it accordingly.

But yes, this approach is not backward compatible, or, rather, backwards 
compatible only after it has been configured 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.

Hmm.

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