[PATCH 3/3] nvmet: include all configured ports in discovery log page for unique discover controller

[Hannes Reinecke]

On 4/5/22 17:09, John Meneghini wrote:
> On 4/5/22 03:31, Christoph Hellwig wrote:
>> 2) (optionally) make the well known discovery controller go away
>>
>> Just renaming the subsystem will make the well known one go away,
>> but while that can be useful for some use cases, I think making it
>> always go away has the potential for breakage.  So maybe we need
>> to not rename but be able to create an alias and have a way to
>> disable the well known discovery controller if not used.
> 
> I agree. I think making the well known discovery controller "go away" 
> will have huge problems in a multi-vendor fabric. We really can't touch 
> the well known discovery controller because there are too many legacy 
> and non-TP-8010 compliant NVMe hosts on the fabric.
> 
> We have to assume that both new and old implementations will coexist. 
> And legacy hosts will NEVER look at the new, unique discovery NQN 
> because they won't even recognize the new NVME_NQN_CURR log page entries.
> 
It doesn't 'go away'.
The original, static, configfs entry will be unused, true.

But the unique discovery subsystem will _still_ react to the default 
discovery NQN, and any controller will continue to get information when 
using the default discovery NQN.

And even older implementations will continue to work _if_ they just skip 
unknown entries.

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