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

[Sagi Grimberg]

>>> Wouldn't it make more sense to delegate explicit registration to
>>> userspace (ie libnvme/nvme-cli), and leave the kernel out of it?
>>
>> It would. There is no reason what-so-ever to place all this register
>> stuff needs to live in the kernel. We have a way to passthru commands so
>> it can and should move to userspace.
> 
> I wish it could be delegated to a user-space app, and in fact that was my
> original design.
> 
> Unfortunately, while testing I realized that the kernel can autonomously
> reconnect and user-space apps are completely unaware of it.
> 
> For example, let's say the network goes down momentarily. The kernel then
> tries to reconnect. Once it successfully reconnects it doesn't tell anyone
> about it.

Then add a uevent on the controller device-node. From there you should
trap it and do what you need (exactly like how discovery log change
events are handled).

BTW, I also don't understand why the host needs this reregistration on
reconnect, but that is besides the point.

> But let's say the kernel does send a signal to user-space on a reconnect.
> What if there is no user-space app to receive this signal? I'm thinking of
> the case where one uses nvme-cli to set up persistent connections to
> discovery controllers.  In that case there is no app to send the explicit
> registration on a re-connect.

This argument does not justify adding functionality in the kernel that
doesn't belong there. If we were to follow this argument we would be
placing everything in the kernel. If someone wants this functionality,
he/she needs to use the tools required for it to work.