[PATCH 3/4] nvme-fabrics: add tp8010 support

[Belanger, Martin]

> > [ .. ]
> >>>> It would be nice to have different events because if we use the
> >>>> "change"
> >>>> uevent for both "log pages have changed" and "connection has been
> >>>> restored", then the user-space app will have to send both an
> >>>> "explicit registration" and a "get log page" whenever it receives a
> "change"
> >>>> uevent.
> >>>> It won’t be able to tell what that "change" uevent is for.
> >>>>
> >>>
> >>> Au contraire.
> >>> Change events come with a full payload detailing out what the event
> >>> is about.
> >>> In the case of a 'log page changed' uevent the event points to the
> >>> controller device, and payload is a string 'NVME_AEN=<aen number>'.
> >>> In the case of the 'path reinstated' uevent the event points to the
> >>> block device.
> >>
> >> There is no *block device*. It's a connection to a Discover Controller.
> >>
> > Ah. Correct. Guess we'll have to add an uevent here.
> 
> Yes, thgere is no bdev for discovery controllers. We may add a uevent for
> userspace to consume as soon as the transport reconnects or when a
> controller (re)starts.
> 
> Don't see any point for the disconnect part as this is async and will not have
> any ordering with the actual disconnect. userspace will need to do it before it
> disconnects the discovery controller.

Hi Sagi. Thanks for the code snippet. I just had a question about your comment.

You say that you don’t see any point to send an event on the disconnect 
because it is async.  I don’t quite understand that part. For example, I've
observed that when connectivity is lost the kernel will try to connect every
10 sec. And it will keep trying to connect 60 times (i.e. 10 min) before 
giving up. Wouldn't sending an "offline" event when connectivity is lost 
give user space apps a heads up that the nvme device may not respond.

Thanks,
Martin

Internal Use - Confidential