[dpdk-dev] Clarification for eth_driver changes

[Shreyansh Jain]

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