From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 4 14:31:55 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFEC0106564A for ; Mon, 4 Apr 2011 14:31:55 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id B17808FC15 for ; Mon, 4 Apr 2011 14:31:55 +0000 (UTC) Received: by pwj8 with SMTP id 8so1829162pwj.13 for ; Mon, 04 Apr 2011 07:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=i3yzNXaP3evrkb/CpPm+cw3hkAFfYiiI1rL6mb+7uLY=; b=P2Nzs1FfHipnaNL1QDz5lZekvxANg/pP+YYwxQApbjQQm6dndx5eR21TIOpzRxTNvo 0IiM+/gqHUCuE2yV1ZLpYEwSme4WttZe2Nhlhlvy/Ps4NGdarmprKG054XeqjOLtARfY 62XRtsJtcItgcYsGAbwcvfjI091BCFNx+9Fl4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=i49GsN27DZXTu5T1+UxzsP6MYAWsX9cPkI2LE7faKjM83axuhqmLAqgT0WwCO7Ydj9 24lN8sS0yQpWjH35de6SHJzWx+6tp3zRsIinvaba9Is87f8A+HBJSZ59hPha8iBrD1nr 5TtY85rfIn1K+sSh5+nTQblPwFFFvKmWt4Q0Q= MIME-Version: 1.0 Received: by 10.143.24.39 with SMTP id b39mr6307593wfj.341.1301927515065; Mon, 04 Apr 2011 07:31:55 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.68.42.3 with HTTP; Mon, 4 Apr 2011 07:31:53 -0700 (PDT) In-Reply-To: <20110404141944.GN71940@rincewind.paeps.cx> References: <20110404141016.GL71940@rincewind.paeps.cx> <20110404141944.GN71940@rincewind.paeps.cx> Date: Mon, 4 Apr 2011 07:31:53 -0700 X-Google-Sender-Auth: EU5Q1u5W6iaZ6Vm6lnE2hiTnHCw Message-ID: From: Garrett Cooper To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Philip Paeps Subject: Re: Updating PCI vendors database X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 14:31:56 -0000 On Mon, Apr 4, 2011 at 7:19 AM, Philip Paeps wrote: > On 2011-04-04 16:10:16 (+0200), Philip Paeps 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 wrote: > > In message: > > ? ? ? ? ? ?Garrett Cooper 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