On Monday 14 November 2016 11:08 PM, Ferruh Yigit wrote: [...] > What I was thinking is: > > rte_device/driver are not abstract classes. > > rte_bus device/driver is an abstract class and any bus inherited from > this class. > rte_func device/driver is and abstract class and eth/crypto inherited > from this class. > > eal layer only deal with rte_bus > pmd's only deal with functional device/driver > > but still, it is required to know device <-> driver, and functional <-> > bus, relations. rte_dev/rte_driver are to provide this links. > > But yes this add extra layer and with second thought I am not sure if it > is really possible to separate bus and functionality, this was just an > idea .. [...]
I understand your point. It would really nice if we can achieve that level pluggable-ness where drivers would be able to choose a 'profile' - where 'profiles' are like net/crypto etc. In your text, profile==functionality. Maybe once the basic model is in place, we can revisit this idea. - Shreyansh