[PATCH 26/35] monitor: implement starting discovery controllers on startup

[Sagi Grimberg]

>>> If the -U/--startup option is used, nvme monitor looks for exsiting
>>> nvme controllers on startup, and runs a discovery on the associated
>>> transport address (connection); i.e. tries to connect to a
>>> discovery
>>> subsystem on the same address, retrieve the discovery log pages,
>>> and (if --autoconnect is given) connect all listed controllers.
>>
>> Oh no no no no... This is a completely wrong assumption to make.
>> Nothing
>> suggest that an nvme controller will have a discovery controller on
>> the
>> same port.
>>
>> There is a discovery controller and an NVM controller, the only
>> connection between the two is that a discovery controller can
>> refer to an nvme controller (or a different discovery controller).
>>
>> Information about discovery controllers may be obtained in different
>> ways, but it absolutely cannot be obtained by any nvme controller.
>>
>> Now I understand a bit more on the --keep discussion. The monitor
>> should today get discovery controller endpoints from a conf file
>> (maybe discovery.conf) and in the future by any other automatic
>> way, not even looking into the currently connected nvme controllers.
>>
> 
> I hear you. I'll drop this in the next version, no problem.
> 
> I didn't expect that probing for a discovery controller was a problem.

It's not a "problem" in the sense that nothing devastating will happen.
it's just wrong. One can also randomize a transport endpoint and attempt
to connect to it.

> IIUC, if we get an fc_udev_device event for a NVMe remote port, we
> can't be sure that that remote port offers a discovery controller,
> either. We try to connect, and give up if it fails.

I'm assuming that this is what the spec mandates the host should do,
which is not the case here.