On Wed, Mar 01, 2017 at 04:56:50PM -0500, Doug Ledford wrote: > isn't a new device in the list already, then great too. Because the > initial implementation proposal left if up to the app to determine > how/when to check for a new device, there was never any guarantee that > whatever triggered the app to look for the new device meant that it was > ready to be used in sysfs No, that isn't true. The kernel guarentees that sysfs is fully setup before it can deliver any sort of event, by any channel, to an app. This includes rdma connection establish, uevents for udev, netlink notifications/etc. > and would be found by the re-reading of the sysfs directory. So > whatever race might be present in my proposed implementation would > also be present in the original implementation. Since the kernel strongly orders things, there is no race in Alex's suggestion. All apps using rdma-cm have to cope with hot plug transparently. An app can 'all device' bind and get an incomming connection from the kernel on a newly plugged device. This must work without having the app do any new steps or introducing races between the rdma-cm channel and some other channel hidden in verbs. > Personally I would use a thread in the library that would block on > inotify events from the sysfs directory. sysfs does not support inotify. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
