Hi Jingjing, On Wed, Jun 07, 2017 at 07:40:37AM +0000, Wu, Jingjing wrote: > > > > > >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? >
Sure. > > 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? > Ah yes, I was actually mistaken and thought more UIO parts would be moving. > > 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? > How do you demux the hotplug_fd for several drivers / device? -- Gaëtan Rivet 6WIND
