Date: Mon, 4 Apr 2011 07:31:53 -0700 From: Garrett Cooper <gcooper@FreeBSD.org> To: hackers@freebsd.org Cc: Philip Paeps <philip@freebsd.org> Subject: Re: Updating PCI vendors database Message-ID: <BANLkTimSJZ_qye_9q_%2Bpp6VGr1kQWLX9tg@mail.gmail.com> In-Reply-To: <20110404141944.GN71940@rincewind.paeps.cx> References: <20110404141016.GL71940@rincewind.paeps.cx> <20110404141944.GN71940@rincewind.paeps.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 4, 2011 at 7:19 AM, Philip Paeps <philip@freebsd.org> wrote: > On 2011-04-04 16:10:16 (+0200), Philip Paeps <philip@freebsd.org> wrote: >> Would anyone object if I updated this list to source the same database u= sed >> 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 actu= ally > work and that we gain (rather than lose) coverage from it. > > A sanity test I've run on a couple of machines: > > =A0% fetch http://pciids.sourceforge.net/v2.2/pci.ids > =A0% pciconf -lv > /tmp/pciconflv.old > =A0% PCICONF_VENDOR_DATABASE=3Dpci.ids pciconf -lv >/tmp/pciconflv.new > =A0% diff -u /tmp/pciconflv.old /tmp/pciconflv.new > > In all cases I've seen so far, the new list yields better (more correct a= nd up > to date) results than the exising list. =A0In no cases has pciconf compla= ined > 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@bsdimp.com> wrote: > > In message: <AANLkTinSojOn182HHYQuAMLqCQNZ=3D6Uqf2FeaEQ8b3vP@mail.gmail= .com> > > ? ? ? ? ? ?Garrett Cooper <yanegomi@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=3Dcsv= ' > fetch: http://www.pcidatabase.com/reports.php?type=3Dcsv: 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 0= 0m00s > 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 =3D re.compile('#.*') > HAS_SUBVENDOR =3D re.compile('^\t\t') > EMPTY_LINE_RE =3D re.compile('^\s*$') > > for line in sys.stdin.readlines(): > if not HAS_SUBVENDOR.search(line): > line =3D COMMENT_RE.sub('', line) > line =3D 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTimSJZ_qye_9q_%2Bpp6VGr1kQWLX9tg>