On 7/11/2018 5:48 AM, Stephen Hemminger wrote:
On Tue, 10 Jul 2018 19:03:27 +0800
Jeff Guo <jia....@intel.com> wrote:
+/* uio pci device state */
+enum rte_udev_state {
+ RTE_UDEV_PROBED,
+ RTE_UDEV_OPENNED,
+ RTE_UDEV_RELEASED,
+ RTE_UDEV_REMOVED,
+};
+
The states here are a little confusing. especially since pci_release
seems to take different actions based on the state. And there is nothing
preventing races between unexpected removal (PCI), and removing the
device from being used by igb_uio.
The states here just manage in igb uio, and only restore the status of
igb uio.
And only the RTE_UDEV_REMOVED that the key status might be a highlight
and process, it is means pci have been removed, then directly come to
igb uio remove without go igb uio release at first,
the status is for hotplug out, need to do specific process. It will no
affect the normal process, and for normal igb uio remove, udev be
release, no any status need to restore.
Would it be possible to only use state variable from the kernel PCI
layer where the value is consistent?
The state which i only care here is hot remove state, i check that
kobj->state_remove_uevent_sent could be use in igb uio,
except that still can not find a specific state of kernel pci to
identify it. If we can find it, it should be best.
what's other comment from guys?
Also there is refcounting in PCI layer (and locking). Could that
be used instead?
It might be, but if state is enough here we might not considerate to use
it. If i am missing anything, let me know.
