> -----Original Message----- > From: David Marchand [mailto:david.march...@6wind.com] > Sent: Wednesday, December 07, 2016 5:52 PM > To: Thomas Monjalon <thomas.monja...@6wind.com> > Cc: Shreyansh Jain <shreyansh.j...@nxp.com>; Hemant Agrawal > <hemant.agra...@nxp.com>; dev@dpdk.org; Richardson, Bruce > <bruce.richard...@intel.com> > Subject: Re: [PATCH 10/32] net/dpaa2: introducing dpaa2 bus driver for fsl-mc > bus > > On Wed, Dec 7, 2016 at 11:40 AM, Thomas Monjalon > <thomas.monja...@6wind.com> wrote: > > 2016-12-07 15:43, Shreyansh Jain: > >> IMO, the way Bus is kept is debatable. > >> - should it be in EAL (lib/librte_eal/linuxapp/eal_pci.c like Bus > >> patches) [1]? > >> - Should it a 'handler/driver' parallel to device drivers? > >> > >> I personally prefer a clean layer for buses with: > >> > >> - RTE_SDK/drivers/net/dpaa2/ > >> - RTE_SDK/drivers/bus > >> - RTE_SDK/drivers/bus/dpaa2/ > >> - RTE_SDK/drivers/bus/dpaa2/dpaa2_bus.c etc. > > > > I agree, it is a good idea. > > Indeed.
[Hemant] I will fix it in v2. > > >> For PCI, which is generic (or for other similar generic buses, like > >> platform), we can keep the implementation within lib/librte_eal/linuxapp/*. > > > > I would be in favor of moving PCI and vdev code from EAL to drivers/bus/. > > We can keep the API in EAL and implement the buses as drivers. > > > > Other opinions? > > The only issue I see for now is how to pass the configuration to these > drivers, > like vdev args or the pci blacklist/whitelist. > > > -- > David Marchand