[PATCH rfc 0/1] Fix missing AENs when discovery controllers are disconnected

[Sagi Grimberg]

>> When a discovery controller is disconnected, no AENs will
>> arrive to notify the host about discovery log-page changes.
>>
>> This attempts to fix it with a new connection parameter asking
>> the kernel to send a dedicated udev event for this case. Prior
>> attempt tried to use "connected" event already sent by the kernel
>> however this also applied on the first connected, causing undesired
>> side-effects when issuing a simple 'discover' command.
>>
>> The patchset includes the nvme-cli/libnvme counter-parts as well.
> 
> Sagi,
> 
> Do we really need another parameter/option ?  seems awkward to need 
> userspace to figure it out.

It has a rather specific use though..

I was looking for something more fine-grained because I initially
used the generic "connected" uevent which had some negative side
effects, so I decided against adding yet another generic "reconnected"
event that nvme-cli would use, and may/may-not fit other use-cases.

I thought its better to have something that is as specific as possible
like "send me an event only when a persistent discovery-controller
reconnects" and I also used the name to indicate the semantic of
the event, so in the future, a possible consumer of this event will
know exactly what it is used for before opting to use it.

> The transport certainly knows the difference between 1st time connect 
> and nth time re-connect - perhaps this should be a simple flag on the 
> nvme ctrl struct set by the transport ?  Simple thing for rdma/tcp to 
> set flag at end of successful xxx_create_ctrl(), while FC, given it does 
> reconnects w/o a first successful connect needs a little more logic.

I used ctrl->nr_reconnects to decide it, which introduced the constraint
that transports would clear it _after_ calling nvme_start_ctrl(). Open
to better suggestions though...