Updating PCI vendors database

[Garrett Cooper]

On Mon, Apr 4, 2011 at 7:19 AM, Philip Paeps <philip at freebsd.org> wrote:
> On 2011-04-04 16:10:16 (+0200), Philip Paeps <philip at freebsd.org> wrote:
>> Would anyone object if I updated this list to source the same database used
>> by Linux distributions at http://pciids.sourceforge.net/v2.2/pci.ids?
>
> It occurs to me that people would want to verify that this list does actually
> work and that we gain (rather than lose) coverage from it.
>
> A sanity test I've run on a couple of machines:
>
>  % fetch http://pciids.sourceforge.net/v2.2/pci.ids
>  % pciconf -lv > /tmp/pciconflv.old
>  % PCICONF_VENDOR_DATABASE=pci.ids pciconf -lv >/tmp/pciconflv.new
>  % diff -u /tmp/pciconflv.old /tmp/pciconflv.new
>
> In all cases I've seen so far, the new list yields better (more correct and up
> to date) results than the exising list.  In no cases has pciconf complained
> about the new list.

    I've copy-pasted the discussion I brought this up to Warner/Brooks
several months ago for review.
    The big problem is that the descriptions with the previous source
and the new source clash, so this would cause a huge amount of diff
churn; plus I think there are a few entries missing from each area (at
least there were the last time I looked -- maybe our pci_vendors is
more spartan than the new source is today).
Thanks,
-Garrett

On Sun, Aug 01, 2010 at 11:10:26PM -0700, Garrett Cooper wrote:
> On Sun, Aug 1, 2010 at 6:12 PM, M. Warner Losh <imp at bsdimp.com> wrote:
> > In message: <AANLkTinSojOn182HHYQuAMLqCQNZ=6Uqf2FeaEQ8b3vP at mail.gmail.com>
> > ? ? ? ? ? ?Garrett Cooper <yanegomi at gmail.com> writes:
> > : Hi Warner and Brooks,
> > : ? ? I'm trying to add some debug code to uart(4) to detect a new PCI
> > : ID and I noticed that some devices were reporting incorrect PCI
> > : descriptions according to the probe output. Ultimately, it turns out
> > : our copy of pci_vendors doesn't have the device (X-Fi audio card), so
> > : it can't find the reference, and it fails to iterate through the
> > : entire bus :(...
> > : ? ? I was looking at http://pciids.sourceforge.net/v2.2/pci.ids
> > : though, and it has this PCI ID (and a lot more PCI IDs). If I write a
> > : conversion tool for this format, would the project be interested in
> > : using it in place of the mk_pci_vendors.pl script?
> >
> > How does this compare with just updating the list that we currently
> > pull from?
>
>     Ran a quick test with a current PCI ID tables:
>
> $ fetch -o vendors.txt 'http://www.pcidatabase.com/reports.php?type=csv'
> fetch: http://www.pcidatabase.com/reports.php?type=csv: size of remote
> file is not known
> vendors.txt                                            495 kB   77 kBps
> $ fetch http://members.datafast.net.au/dft0802/downloads/pcidevs.txt
> pcidevs.txt                                   100% of  840 kB  124 kBps
> $ perl /usr/src/tools/tools/pciid/mk_pci_vendors.pl | awk '! /;/' | wc -l
>    11218
>
>     Versus my script:
>
> $ fetch -o - http://pciids.sourceforge.net/v2.2/pci.ids |
> ~/parse-pci-ids.py  | wc -l
> -                                             100% of  644 kB   54 kBps 00m00s
>    11317
> $ wc -l ~/pci-vendors-table
>     11236 /usr/home/gcooper/pci-vendors-table
>
>     There isn't as much difference as I thought (a lot of the pci.ids
> table was subdevices, oddly enough).
>     Here's my script (not polished with the note stating that it's
> autogenerated, etc). Yes, I know I could have written it in awk or
> perl, but I just wanted to try and see what the difference was :)...
> Thanks,
> -Garrett
>
> #!/usr/bin/env python
>
> import re
> import sys
>
> COMMENT_RE = re.compile('#.*')
> HAS_SUBVENDOR = re.compile('^\t\t')
> EMPTY_LINE_RE = re.compile('^\s*$')
>
> for line in sys.stdin.readlines():
>     if not HAS_SUBVENDOR.search(line):
>         line = COMMENT_RE.sub('', line)
>         line = EMPTY_LINE_RE.sub('', line)
>         if line:
>             sys.stdout.write(line)
>

I can see adding this to the list of inputs as a backup to the other
two.  I can't really see throwing out the current entries and causing
churn in descriptions.

-- Brooks