> > > >Secondly, in order to read out the uevent that monitoring, we need to add > >uevent API in rte > layer. We plan add 2 , rte_uevent_connect and rte_get_uevent. All driver > interrupt handler > could use these API to enable the uevent monitoring, and read out the uevent > type , then > corresponding to handle these uevent, such as detach the device when get the > remove type. > > > > I find having a generic uevent API interesting. > > However, all specifics pertaining to UIO use (hotplug_fd, subsystem > enum) should stay in UIO specific code (eal_pci_uio.c?). > Yes, but it can be also considered as interrupt mechanism, right?
> I am currently moving the PCI bus out of the EAL. EAL subsystems should > not rely on PCI specifics, as they won't be available afterward. Will the interrupt handling be kept in EAL, right? > It should also allow you to clean up your API. Exposing hotplug_fd and > requiring PMDs to link it can be avoided and should result in a simpler > API. Didn't get the idea. Why it will result in a simpler API? Is there any patch help Me to understand? Thanks Jingjing
