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

[Sagi Grimberg]

>>> The current problem we're having (on linux) is that we cannot 
>>> identify discovery controllers. Each discovery controller has the 
>>> same subsystem NQN, and hence that's not sufficient to identify the 
>>> subsystem
>>> Which resulted in linux to always create a new 'nvme_subsystem' 
>>> instance when creating a new nvme discover controller.
>>
>> That is the case regardless of naming... there is no multipathing with
>> discovery subsystems so there will be a subsystem for every discovery
>> controller...
>>
> Well, technically, no, but in practice there is, as one can easily 
> specify more than one discovery port (to the same discovery subsystem).
> And quite some target implementations do.
> Discussion is probably moot anyway as multipathing would only affect 
> I/O, which won't be done anyway.

It is a moot discussion.

>>> Problem now starts when you try to use persistent discovery 
>>> controllers; it's quite easy to _create_ a persistent discovery 
>>> controller, but less easy to _use_ an existing one; how would you 
>>> know which one to pick?
>>
>> You are not supposed to "use" an existing one, the whole point of the
>> persistent discovery controllers is that you don't need to worry about
>> it. We already perfectly handle that with udev using the kernel of
>> the uevent.
>>
> 
> And my point is that you _do_. Yes, udev does work, but only in so far 
> AENs are involved.

Why do you need persistent discovery controllers if you don't want the
AEN?

> When you want to retrieve the discovery log manually 
> _and_ have existing persistent discovery controllers you'll need to know 
> which device to pick.

Please describe the use-case because I still don't understand.
nvme-cli offers 'discover' that gives you the log page and 'connect-all'
that connects to the subsystems it found in the log page.

Do you have foreign udev rules in addition to the ones supplied in
nvme-cli? I am missing the problem statement that you are alluding to.

> Which is getting especially interesting if you have several different 
> subsystems to contend with.

I still don't understand what you are describing.