Re: [PATCH v2 3/3] nvme: fire discovery log page change events to userspace

[Sagi Grimberg]

> > > > > Yes we do, userspace should use it to order events. Does udev not
> > > > > handle that properly today?
> > > >
> > > > The problem is not ordering of events, its really about the fact that
> > > > the chardev can be removed and reallocated for a different controller
> > > > (could be a completely different discovery controller) by the time
> > > > that userspace handles the event.
> > >
> > > The same is generally true for lot of kernel devices. We could reduce
> > > the chance by using the idr cyclic allocator.
> >
> > Well, it was raised by Hannes and James, so I'll ask them respond here
> > because I don't mind having it this way. I personally think that this
> > is a better approach than having a cyclic idr allocator. In general, I
> > don't necessarily think that this is a good idea to have cyclic
> > controller enumerations if we don't absolutely have to...
>
> We hit it right and left without the cyclic allocator, but that won't 
> necessarily remove it.
>
> Perhaps we should have had a unique token assigned to the controller, 
> and have the event pass the name and the token. The cli would then, if 
> the token is present, validate it via an ioctl before proceeding with 
> other ioctls.
>
> Where all the connection arguments were added we due to the reuse issue 
> and then solving the question of how to verify and/or lookup the desired 
> controller, by using the shotgun approach rather than being very 
> pointed, which is what the name/token would do.

This unique token is: trtype:traddr:trsvcid:host-traddr ...