> -----Original Message----- > From: David Marchand [mailto:[email protected]] > Sent: Wednesday, December 07, 2016 5:52 PM > To: Thomas Monjalon <[email protected]> > Cc: Shreyansh Jain <[email protected]>; Hemant Agrawal > <[email protected]>; [email protected]; Richardson, Bruce > <[email protected]> > 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 > <[email protected]> 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
