Re: Updating PCI vendors database
On Mon, Apr 04, 2011 at 08:30:38PM -0700, Garrett Cooper wrote: On Mon, Apr 4, 2011 at 11:04 AM, Doug Barton do...@freebsd.org wrote: On 04/04/2011 07:10, Philip Paeps wrote: It looks like our /usr/share/misc/pci_vendors list (used only by pciconf as far as I can tell) has become rather stale. ?We also appear to be tracking sources which no longer exist. 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 helps that our pciconf looks to be compatible with that format. ?We just ignore subvendor and subdevice, but it doesn't appear to matter that the file contains this information. I could cull the subvendor/subdevice from the list though. Any views? Having read this thread, and the last one, my opinion is, let's do it already. :) ?Repo churn should not, under any circumstances, be a consideration in technical improvements. I agree with those who have said that the new list should be confirmed to be a superset of the old, and anything missing should be merged in. Checking with Jack about Intel stuff is also reasonable, as would be cross-checking with what NetBSD and OpenBSD are doing (and perhaps communicating with them about your work). 1. People may have automation that depends on this output. This was my only concern about churn in the previous conversation. Given that the lists were using are defunct, we should just move to pci.ids unless someone verifies that a signficant number of devices are missing. If that were to happen I'd just add a local source file to merge into pci.ids and let pci.ids be the master. -- Brooks pgp76MOeGNIEh.pgp Description: PGP signature
Updating PCI vendors database
It looks like our /usr/share/misc/pci_vendors list (used only by pciconf as far as I can tell) has become rather stale. We also appear to be tracking sources which no longer exist. 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 helps that our pciconf looks to be compatible with that format. We just ignore subvendor and subdevice, but it doesn't appear to matter that the file contains this information. I could cull the subvendor/subdevice from the list though. Any views? Reason I'm looking into this is because one of my customers would like their name to be correct when I import the driver I've been working on for them. :) - Philip -- Philip PaepsPlease don't Cc me, I am phi...@freebsd.org subscribed to the list. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Updating PCI vendors database
On 2011-04-04 16:10:16 (+0200), Philip Paeps phi...@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. - Philip -- Philip PaepsPlease don't Cc me, I am phi...@freebsd.org subscribed to the list. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Updating PCI vendors database
On Mon, Apr 4, 2011 at 7:19 AM, Philip Paeps phi...@freebsd.org wrote:
On 2011-04-04 16:10:16 (+0200), Philip Paeps phi...@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 i...@bsdimp.com wrote:
In message: AANLkTinSojOn182HHYQuAMLqCQNZ=6uqf2feaeq8b...@mail.gmail.com
? ? ? ? ? ?Garrett Cooper yaneg...@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.txt495 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
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Updating PCI vendors database
on 04/04/2011 17:10 Philip Paeps said the following: It looks like our /usr/share/misc/pci_vendors list (used only by pciconf as far as I can tell) has become rather stale. We also appear to be tracking sources which no longer exist. 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 helps that our pciconf looks to be compatible with that format. We just ignore subvendor and subdevice, but it doesn't appear to matter that the file contains this information. I could cull the subvendor/subdevice from the list though. Any views? Reason I'm looking into this is because one of my customers would like their name to be correct when I import the driver I've been working on for them. :) This is just for your information: http://thread.gmane.org/gmane.os.freebsd.current/127979/focus=128577 Maybe you'll find something useful there. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Updating PCI vendors database
On 2011-04-04 07:31:53 (-0700), Garrett Cooper gcoo...@freebsd.org wrote: On Mon, Apr 4, 2011 at 7:19 AM, Philip Paeps phi...@freebsd.org wrote: On 2011-04-04 16:10:16 (+0200), Philip Paeps phi...@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. I think at that point, the lists we're currently sourcing still existed. As of this morning, I don't seem to be able to find Craig Hart's list of PCI IDs anywhere on the net. It's certainly no long available at the address listed in the source tree. 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; This would be a problem I agree, but not a huge one. If the churn would be too large, I would be hesitant to push this to any stable branches. But I don't think the churn should be a problem for HEAD. It doesn't look to me like the churn is too large on the machines I've used it on. Generally, the changes I've seen is devices which lacked a device description now have one, and devices which had a wrong or incomplete description now have a complete and (as far as I can tell) correct one. This feels like an improvement to me. :) 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). The new list is much more complete than the list we have currently. For one thing, it also includes subvendors and subdevices, which the current list lacks. Our pciconf doesn't care about those currently, but could be made to care. I also don't think we should underestimate the value of sharing a list with Linux (especially if the licence on the list is friendly to sharing it) and potentially other operating system vendors. - Philip -- Philip PaepsPlease don't Cc me, I am phi...@freebsd.org subscribed to the list. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Updating PCI vendors database
On 2011-04-04 17:39:22 (+0300), Andriy Gapon a...@freebsd.org wrote: on 04/04/2011 17:10 Philip Paeps said the following: It looks like our /usr/share/misc/pci_vendors list (used only by pciconf as far as I can tell) has become rather stale. We also appear to be tracking sources which no longer exist. 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 helps that our pciconf looks to be compatible with that format. We just ignore subvendor and subdevice, but it doesn't appear to matter that the file contains this information. I could cull the subvendor/subdevice from the list though. Any views? Reason I'm looking into this is because one of my customers would like their name to be correct when I import the driver I've been working on for them. :) This is just for your information: http://thread.gmane.org/gmane.os.freebsd.current/127979/focus=128577 Maybe you'll find something useful there. Thanks. I've just read through that discussion. It doesn't look like there were any serious objections to pulling in the new list, other than verifying that the new list contains all the entries the current list contains. I am not entirely sure what the little side-discussion about using # instead of ; as a comment marker is about. It looks to me like the pci.ids file Just Works[tm] with our pciconf(8). Maybe Garrett can elaborate on that? I think we should just go with the new list, but I'll hold off for a bit to let others object. ;) - Philip -- Philip PaepsPlease don't Cc me, I am phi...@freebsd.org subscribed to the list. You can't fix it if it ain't broke. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Updating PCI vendors database
On Mon, Apr 4, 2011 at 7:57 AM, Philip Paeps phi...@freebsd.org wrote:
On 2011-04-04 17:39:22 (+0300), Andriy Gapon a...@freebsd.org wrote:
on 04/04/2011 17:10 Philip Paeps said the following:
It looks like our /usr/share/misc/pci_vendors list (used only by pciconf as
far as I can tell) has become rather stale. We also appear to be tracking
sources which no longer exist.
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 helps that our pciconf looks to be compatible with that format. We just
ignore subvendor and subdevice, but it doesn't appear to matter that the
file
contains this information.
I could cull the subvendor/subdevice from the list though.
Any views?
Reason I'm looking into this is because one of my customers would like
their
name to be correct when I import the driver I've been working on for them.
:)
This is just for your information:
http://thread.gmane.org/gmane.os.freebsd.current/127979/focus=128577
Maybe you'll find something useful there.
Thanks. I've just read through that discussion. It doesn't look like there
were any serious objections to pulling in the new list, other than verifying
that the new list contains all the entries the current list contains.
I am not entirely sure what the little side-discussion about using # instead
of ; as a comment marker is about. It looks to me like the pci.ids file Just
Works[tm] with our pciconf(8). Maybe Garrett can elaborate on that?
Well, close. You can substitute the hashes with semicolons, but you
need to get rid of subvendor / subdevice.
The format is:
vendor-id\040\040vendor-description
\011device-id\040\040device-description
\011\011subvendor-id\040subdevice-id\040\040subsystem-name
(it's also documented in the top of the file, but just to be pedantic
I noted it here)
pciconf already supports hash based comments:
/*
* Scan input lines from the database
*/
for (;;) {
if (fgets(buf, sizeof(buf), db) == NULL)
break;
if ((ch = strchr(buf, '#')) != NULL)
*ch = '\0';
so no work needs to be done there.
Setting PCICONF_VENDOR_DATABASE to pci.ids worked, but all the items
on my box are different in the new file (all device descriptions, but
also some of the vendor descriptions dealing with my nVidia card,
Realtek NIC, and LSI card) [it would be interesting to see who's
correct in terms of corporation branding :)..]. So this definitely
isn't MFC-able :).
I think we should just go with the new list, but I'll hold off for a bit to
let others object. ;)
+1, just for the fact that our sources are becoming stale. I wonder
though what other OSes like NetBSD/OpenBSD/[Open]Solaris/IlluminOS use
however for tracking PCI IDs, as the sources for pci.ids aren't
necessarily the vendor itself and in some cases are end-users. I
thought some of our other sources were based on data provided by
vendors.
Thanks,
-Garrett
pci-vendors.output
Description: Binary data
pci-ids.output
Description: Binary data
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Updating PCI vendors database
On 2011-04-04 08:51:03 (-0700), Garrett Cooper yaneg...@gmail.com wrote: On Mon, Apr 4, 2011 at 7:57 AM, Philip Paeps phi...@freebsd.org wrote: On 2011-04-04 17:39:22 (+0300), Andriy Gapon a...@freebsd.org wrote: on 04/04/2011 17:10 Philip Paeps said the following: 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 helps that our pciconf looks to be compatible with that format. We just ignore subvendor and subdevice, but it doesn't appear to matter that the file contains this information. [...] This is just for your information: http://thread.gmane.org/gmane.os.freebsd.current/127979/focus=128577 Maybe you'll find something useful there. Thanks. I've just read through that discussion. It doesn't look like there were any serious objections to pulling in the new list, other than verifying that the new list contains all the entries the current list contains. I am not entirely sure what the little side-discussion about using # instead of ; as a comment marker is about. It looks to me like the pci.ids file Just Works[tm] with our pciconf(8). Maybe Garrett can elaborate on that? Well, close. You can substitute the hashes with semicolons, but you need to get rid of subvendor / subdevice. The presence of the subvendor/subdevice entries doesn't appear to affect the correctness of the output on the machines I've tested it on. Cursorily reading through the pciconf(8) source code suggests it ignores that data (and as it happens the presence of subvendors and subdevices). I think the most correct thing to do would be to teach pciconf(8) about subvendors and subdevices and pull in the new list as-is. I'll take a look at adding support for that later today. It shouldn't be much work. Setting PCICONF_VENDOR_DATABASE to pci.ids worked, but all the items on my box are different in the new file (all device descriptions, but also some of the vendor descriptions dealing with my nVidia card, Realtek NIC, and LSI card) [it would be interesting to see who's correct in terms of corporation branding :)..]. So this definitely isn't MFC-able :). It doesn't look like they're fundamentally different through. The strings changed, but still seem to be describing the same devices. I'm happy to agree that this isn't MFC-able. I think we should just go with the new list, but I'll hold off for a bit to let others object. ;) +1, just for the fact that our sources are becoming stale. I wonder though what other OSes like NetBSD/OpenBSD/[Open]Solaris/IlluminOS use however for tracking PCI IDs, as the sources for pci.ids aren't necessarily the vendor itself and in some cases are end-users. I thought some of our other sources were based on data provided by vendors. A comment from jfv@ in the thread from a few months ago, suggests that at least Intel contributes directly to the pci.ids list. One measurement isn't a valid statistic though. - Philip -- Philip PaepsPlease don't Cc me, I am phi...@freebsd.org subscribed to the list. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Updating PCI vendors database
Philip Paeps ha scritto: This is just for your information: http://thread.gmane.org/gmane.os.freebsd.current/127979/focus=128577 Maybe you'll find something useful there. Thanks. I've just read through that discussion. It doesn't look like there were any serious objections to pulling in the new list, other than verifying that the new list contains all the entries the current list contains. The discussion went on privately (dunno why) beetween John, Warner, Brooks, me and a few others. I suggest you to contact John Baldwin before taking actions, I've updated also the merged lists. -- Alex Dupre ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Updating PCI vendors database
On 2011-04-04 17:44:29 (+0200), Alex Dupre a...@freebsd.org wrote: Philip Paeps ha scritto: This is just for your information: http://thread.gmane.org/gmane.os.freebsd.current/127979/focus=128577 Maybe you'll find something useful there. Thanks. I've just read through that discussion. It doesn't look like there were any serious objections to pulling in the new list, other than verifying that the new list contains all the entries the current list contains. The discussion went on privately (dunno why) beetween John, Warner, Brooks, me and a few others. I suggest you to contact John Baldwin before taking actions, I've updated also the merged lists. Thanks. I'll talk to them. - Philip -- Philip PaepsPlease don't Cc me, I am phi...@freebsd.org subscribed to the list. I thought that said Windows has been installed for your safety. -- SlimeyPete, looking at safety signs on a train ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Updating PCI vendors database
On Apr 4, 2011, at 10:01 AM, Philip Paeps wrote: I think we should just go with the new list, but I'll hold off for a bit to let others object. ;) +1, just for the fact that our sources are becoming stale. I wonder though what other OSes like NetBSD/OpenBSD/[Open]Solaris/IlluminOS use however for tracking PCI IDs, as the sources for pci.ids aren't necessarily the vendor itself and in some cases are end-users. I thought some of our other sources were based on data provided by vendors. A comment from jfv@ in the thread from a few months ago, suggests that at least Intel contributes directly to the pci.ids list. One measurement isn't a valid statistic though. Since the old list appears to have disappeared, I'd go with the new one. There were patches floating about even. The new list had worse coverage than the old one for some old PCI gear, so I suggested using the new one in preference to the old one and if there were good entries in the old one to try to merge those into the new one over time and wean us from the old one. If the old one is gone, the path forward is clear. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Updating PCI vendors database
On 04/04/2011 07:10, Philip Paeps wrote: It looks like our /usr/share/misc/pci_vendors list (used only by pciconf as far as I can tell) has become rather stale. We also appear to be tracking sources which no longer exist. 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 helps that our pciconf looks to be compatible with that format. We just ignore subvendor and subdevice, but it doesn't appear to matter that the file contains this information. I could cull the subvendor/subdevice from the list though. Any views? Having read this thread, and the last one, my opinion is, let's do it already. :) Repo churn should not, under any circumstances, be a consideration in technical improvements. I agree with those who have said that the new list should be confirmed to be a superset of the old, and anything missing should be merged in. Checking with Jack about Intel stuff is also reasonable, as would be cross-checking with what NetBSD and OpenBSD are doing (and perhaps communicating with them about your work). So, not a slam-dunk, but definitely a clear path forward. Oh, and I personally don't see a problem with MFC'ing this, but I'm willing to be convinced. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Updating PCI vendors database
On 2011-04-04 11:04:38 (-0700), Doug Barton do...@freebsd.org wrote: On 04/04/2011 07:10, Philip Paeps wrote: It looks like our /usr/share/misc/pci_vendors list (used only by pciconf as far as I can tell) has become rather stale. We also appear to be tracking sources which no longer exist. 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 helps that our pciconf looks to be compatible with that format. We just ignore subvendor and subdevice, but it doesn't appear to matter that the file contains this information. I could cull the subvendor/subdevice from the list though. Any views? Having read this thread, and the last one, my opinion is, let's do it already. :) I'll wait a little longer for more comments but then: yes, I'll go and do it. Repo churn should not, under any circumstances, be a consideration in technical improvements. I agree with those who have said that the new list should be confirmed to be a superset of the old, and anything missing should be merged in. Checking with Jack about Intel stuff is also reasonable, as would be cross-checking with what NetBSD and OpenBSD are doing (and perhaps communicating with them about your work). So, not a slam-dunk, but definitely a clear path forward. Oh, and I personally don't see a problem with MFC'ing this, but I'm willing to be convinced. I was thinking of putting it in head and waiting a good while for the screaming to subside and the fires to go out before raising the idea of merging it to stable. Barring any clear counterindications, I'll just do this in the next day or so. - Philip -- Philip PaepsPlease don't Cc me, I am phi...@freebsd.org subscribed to the list. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Updating PCI vendors database
On Mon, Apr 4, 2011 at 11:04 AM, Doug Barton do...@freebsd.org wrote: On 04/04/2011 07:10, Philip Paeps wrote: It looks like our /usr/share/misc/pci_vendors list (used only by pciconf as far as I can tell) has become rather stale. We also appear to be tracking sources which no longer exist. 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 helps that our pciconf looks to be compatible with that format. We just ignore subvendor and subdevice, but it doesn't appear to matter that the file contains this information. I could cull the subvendor/subdevice from the list though. Any views? Having read this thread, and the last one, my opinion is, let's do it already. :) Repo churn should not, under any circumstances, be a consideration in technical improvements. I agree with those who have said that the new list should be confirmed to be a superset of the old, and anything missing should be merged in. Checking with Jack about Intel stuff is also reasonable, as would be cross-checking with what NetBSD and OpenBSD are doing (and perhaps communicating with them about your work). 1. People may have automation that depends on this output. 2. Some braindead SCMs may be problematic with this change (p4? *COUGH*). Someone at $WORK recently backported a copy of pci_vendors from CURRENT to STABLE without any issues (needed a few PCI IDs for new hardware), but that might not have been as true with this shift to using pci.ids. So, not a slam-dunk, but definitely a clear path forward. Oh, and I personally don't see a problem with MFC'ing this, but I'm willing to be convinced. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Updating PCI vendors database
On 04/04/2011 20:30, Garrett Cooper wrote: 1. People may have automation that depends on this output. To the extent that they rely on information that is out of date, fixing this is a feature. However I cannot imagine that this would be much of an issue. 2. Some braindead SCMs may be problematic with this change (p4?*COUGH*). Eh? I don't parse this. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Updating PCI vendors database
On Mon, Apr 4, 2011 at 9:30 PM, Doug Barton do...@freebsd.org wrote: On 04/04/2011 20:30, Garrett Cooper wrote: 1. People may have automation that depends on this output. To the extent that they rely on information that is out of date, fixing this is a feature. However I cannot imagine that this would be much of an issue. 2. Some braindead SCMs may be problematic with this change (p4?*COUGH*). Eh? I don't parse this. perforce doesn't always grok large changes (especially deletions -- it gets ditzy). The last change that was committed by someone at $WORK to this file was several thousand lines long, and that was just additions IIRC. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Updating PCI vendors database
On 04/04/2011 21:36, Garrett Cooper wrote: 2. Some braindead SCMs may be problematic with this change (p4?*COUGH*). Eh? I don't parse this. perforce doesn't always grok large changes (especially deletions -- it gets ditzy). The last change that was committed by someone at $WORK to this file was several thousand lines long, and that was just additions IIRC. Thanks for bringing this up, but I don't care. :) The tools serve us, not the other way around. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
