Bug 178487 - hwdata pci.ids and pcitable directories for 3rd parties to add/update entries (P2)
hwdata pci.ids and pcitable directories for 3rd parties to add/update entries...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: pciutils (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
: FutureFeature, Reopened
Depends On:
Blocks: 170416 185127 195327 237301
  Show dependency treegraph
 
Reported: 2006-01-20 17:34 EST by Matt Domsch
Modified: 2010-10-21 23:54 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-18 10:36:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matt Domsch 2006-01-20 17:34:27 EST
Description of problem:
Today, when using tools like DKMS to replace kernel modules, drivers typically
also muck with the pci.ids and pcitable files provided by the hwdata package, to
get lspci to properly display their new hardware, and for kudzu to detect the
new PCI IDs to match to their drivers (less critical on 2.6 kernels now).

It would be be beneficial if, rather than looking in a single pci.ids file, that
there be a directory that those apps look in (as well as pci.ids file), for
additional or updated entries.  Then DKMS packages could add their own files in
that directory, rather than editing pci.ids itself (and sometimes messing it up).

hwdata would own the newly created directory(s).  kudzu and pciutils would need
to be updated to look on those new directories too.
Comment 1 Phil Knirsch 2006-01-31 10:38:27 EST
That sounds like a pretty good idea. Although i don't think we can do this
change for our currently shipped Red Hat Enterprise Linux version this could be
a good idea for the next version.

Read ya, Phil
Comment 2 Matt Domsch 2006-02-03 00:02:21 EST
Upstream rejected in favor of having people use update-pciids.sh to download 
newer versions from pciids.sf.net.  I'll leave this open for now though.
Comment 3 Issue Tracker 2006-02-04 17:04:26 EST
From User-Agent: XML-RPC

Bug 178582 is related
[Charles_Rose@dell.com]


This event sent from IssueTracker by ltroan
 issue 87336
Comment 4 Issue Tracker 2006-02-22 15:05:21 EST
From User-Agent: XML-RPC

PM review rates this as a P2. Will be considered for U4 but will not hold
Update if it doesn't work.

Priority set to: 2
Summary edited.

This event sent from IssueTracker by ltroan
 issue 87336
Comment 5 Larry Troan 2006-02-22 15:12:23 EST
Regarding comment #3 above, bug 178582 provides an automated way to refresh the
PCI ID information so that lspci should not return "Unknown Device" which
generates field support calls. This ability requires access to an external network.

This bug 178487 provides a local back-up where IHVs and others can load a table
to resolve adapter names in the event the box doesn't have access to the
network. It's analagous to the /etc/hosts file when DNS is not available.
Comment 9 RHEL Product and Program Management 2006-06-14 17:18:33 EDT
Product Management has reviewed and declined this request.  You may appeal this decision by reopening this request.
Comment 10 Larry Troan 2006-06-23 13:16:49 EDT
Jon, you may want to reconsider this in regards to Bug 182604.
Comment 12 Larry Troan 2007-07-04 23:32:12 EDT
Reopened by Dell for 4.6 consideration.
Comment 15 Phil Knirsch 2007-08-02 09:29:08 EDT
See comment #14, moving bug to RHEL-4.7.0

Additionally, this is actually a change that needs to go into pciutils, so
reassigning to proper component at the same time.

Read ya, Phil
Comment 18 RHEL Product and Program Management 2008-02-01 14:13:36 EST
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".

Note You need to log in before you can comment on or make changes to this bug.