Hello, On Wed, Jan 6, 2016 at 2:40 AM, Thomas Monjalon <thomas.monjalon at 6wind.com> wrote:
> 2016-01-05 11:37, Stephen Hemminger: > > Has anyone looked at getting rid of rte_pci_dev_ids.h? > > The current method with #ifdef's and putting all devices in one file > > really doesn't scale well. Something more like other OS's where > > the data is only in each device driver would be better. > > I agree. > The PCI ids should be embedded in drivers. > If I remember well, it's already the case for some of them. > I would love to see a tool able to list the supported devices > by reading a binary libraries. > I have done the first part of the job, moving all pci dev ids to the pmds, just rebased it. I can post this. In the last patch of the series, I put all those ids in a dedicated section, that can be dumped with objdump. Having a tool for this (like what I proposed some time ago) would be great but I did not find time to write it. The thing is, what do we want to achieve with such a tool ? My usecase at the moment is for "automatic" device binding to kernel drivers before starting dpdk or when hotplugging. But for this, I think that introducing a hook system in the pci probe functions is better. I am thinking of a hook system that would execute an external tool (shell scripts, C, ...) with all needed informations: pci device, pmd that wants it, driver flags etc... Return value would tell eal what to do next. This would make it possible to implement the blacklist / whitelist out of eal itself, implement auto bind and maybe more. If I go this way, I don't think that we need to expose the pci dev ids :-) -- David Marchand
