On Wed, Jun 28, 2017 at 1:44 PM, Thomas Monjalon <tho...@monjalon.net> wrote: > 27/06/2017 21:03, Jan Blunck: >> On Tue, Jun 27, 2017 at 6:11 PM, Gaetan Rivet <gaetan.ri...@6wind.com> wrote: >> > --- a/lib/librte_eal/common/include/rte_bus.h >> > +++ b/lib/librte_eal/common/include/rte_bus.h >> > /** >> > + * Implementation specific probe function which is responsible for linking >> > + * devices on that bus with applicable drivers. >> > + * The plugged device might already have been used previously by the bus, >> > + * in which case some buses might prefer to detect and re-use the relevant >> > + * information pertaining to this device. >> > + * >> > + * @param da >> > + * Device declaration. >> > + * >> > + * @return >> > + * The pointer to a valid rte_device usable by the bus on success. >> > + * NULL on error. rte_errno is then set. >> > + */ >> > +typedef struct rte_device * (*rte_bus_plug_t)(struct rte_devargs *da); >> >> Shouldn't this be orthogonal to unplug() and take a rte_device. You >> should only be able to plug devices that have been found by scan >> before. > > Plugging a device that has been scanned before is a special case. > In a true hotplug scenario, we could use this plug function passing > a devargs. > I don't see any issue passing rte_devargs to plug and rte_device to unplug.
What do you mean by "true hotplug"? The problem with this is that passing just rte_devargs to plug() requires the bus to parse and enrich the rte_devargs with bus specifics. From there it gets folded into the to-be-created bus specific rte_XXX_device. This makes it unnecessarily complicated and even worse it adds a second code path how devices come alive. When we get notified about a hotplug event we already know which bus this event belongs to: 1. scan the bus for incoming devices 2. plug single device with devargs and probe for drivers Makes sense?
