[lkml]   [2019]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2 3/3] nvme: fire discovery log page change events to userspace

>>>>> 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 ...

 \ /
  Last update: 2019-08-30 23:07    [W:0.059 / U:4.872 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site