Hello Ferruh, (Please ignore if line wrappings are not correct. Using a possibly unconfigured mail client).
> -----Original Message----- > From: Ferruh Yigit [mailto:ferruh.yigit at intel.com] > Sent: Saturday, November 12, 2016 12:46 AM > To: Shreyansh Jain <shreyansh.jain at nxp.com>; David Marchand > <david.marchand at 6wind.com> > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] Clarification for eth_driver changes > > On 11/10/2016 11:05 AM, Shreyansh Jain wrote: > > Hello David, > > > > On Thursday 10 November 2016 01:46 PM, David Marchand wrote: > >> Hello Shreyansh, > >> > >> On Thu, Nov 10, 2016 at 8:26 AM, Shreyansh Jain <shreyansh.jain at nxp.com> > wrote: > >>> I need some help and clarification regarding some changes I am doing to > >>> cleanup the EAL code. > >>> > >>> There are some changes which should be done for eth_driver/rte_eth_device > >>> structures: > >>> > >>> 1. most obvious, eth_driver should be renamed to rte_eth_driver. > >>> 2. eth_driver currently has rte_pci_driver embedded in it > >>> - there can be ethernet devices which are _not_ PCI > >>> - in which case, this structure should be removed. > >> > >> Do we really need to keep a eth_driver ? > > > > No. As you have rightly mentioned below (as well as in your Jan'16 > > post), it is a mere convenience. > > Isn't it good to separate the logic related which bus device connected > and what functionality it provides. Because these two can be flexible: Indeed. The very idea of a Bus model is to make a hierarchy which allows for pluggability/flexibility in terms of devices being used. But, until now I have only considered placement hierarchy and not functional hierarchy. (more below) > > device -> virtual_bus -> ethernet_functionality > device -> pci_bus -> crypto_functionality > device -> x_bus -> y_function > Ok. > > what about: > > create generic bus driver/device and all eal level deal with generic > bus. different buses inherit from generic bus logic
