Bug 178487

Summary:	hwdata pci.ids and pcitable directories for 3rd parties to add/update entries (P2)
Product:	Red Hat Enterprise Linux 4	Reporter:	Matt Domsch <matt_domsch>
Component:	pciutils	Assignee:	Harald Hoyer <harald>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.0	CC:	herrold, jcm, jfeeney, pknirsch, tao, wwlinuxengineering
Target Milestone:	---	Keywords:	FutureFeature, Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-08-18 14:36:50 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	170416, 185127, 195327, 237301

Description Matt Domsch 2006-01-20 22:34:27 UTC

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 15:38:27 UTC

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 05:02:21 UTC

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 22:04:26 UTC

From User-Agent: XML-RPC

Bug 178582 is related
[Charles_Rose]


This event sent from IssueTracker by ltroan
 issue 87336

Comment 4 Issue Tracker 2006-02-22 20:05:21 UTC

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 20:12:23 UTC

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 Program Management 2006-06-14 21:18:33 UTC

Product Management has reviewed and declined this request.  You may appeal this decision by reopening this request.

Comment 10 Larry Troan 2006-06-23 17:16:49 UTC

Jon, you may want to reconsider this in regards to Bug 182604.

Comment 12 Larry Troan 2007-07-05 03:32:12 UTC

Reopened by Dell for 4.6 consideration.

Comment 15 Phil Knirsch 2007-08-02 13:29:08 UTC

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 Program Management 2008-02-01 19:13:36 UTC

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 "?".