Update pcihdr.h

[johndrinkwater]

This file is dated 30 Jun 2003 and could do with an update.

[johndrinkwater]

After having words with Korli on IRC; A script it required to make updating this file easier; the output from the source isn't the cleanest in the world.

Jan 17 18:52:50 <Korli> [Beta] the problem is the one I can find is pretty dirty : I have to clean up bad entries myself, weird <Korli> you'll see there are some bad values in it <Korli> maybe a regular expression could filter it to check for good entries <Korli> this one is funny : { 0x11D1, VXP520, "tag4769", "Video card" } , <Korli> some even don't have vendor and device names, they are useless <Korli> a little script could be written, filtering this file and committed along the pci header to ease future updates

[johndrinkwater]

First revision of the PCI header cleaner

[korli]

I did a test and result is :

/boot/home/svnhaiku/trunk/src/preferences/devices/pcihdr.h:3453: unknown escape sequence `\V' /boot/home/svnhaiku/trunk/src/preferences/devices/pcihdr.h:3541: unknown escape sequence `\V' /boot/home/svnhaiku/trunk/src/preferences/devices/pcihdr.h:3701: unknown escape sequence `\M' /boot/home/svnhaiku/trunk/src/preferences/devices/pcihdr.h:5625: unknown escape sequence `\V'

I think you should replace '\' with '
'. Thanks.

[korli]

I committed a fixed header, but I doubt it's usable after all, ie vendor info for the vga device in VPC : { 0x5333, "S3 Graphics", "kevin humphreys" }. It's just an example of wrong data, which were good before. I think I'll revert to the previous version, I can't see how to solve this header with such bad information. Maybe we should take a pci header from another OS instead.

[korli]

Could you have a look at ​http://pciids.sourceforge.net/ ? It seems license compatible and clean. We would need a script (awk ?) to convert pci.ids in a valider header. [Beta], what's your opinion ?

[johndrinkwater]

I'll look into it..

Please, revert the pcihdr.h change; i'd hope we could get a clean (and filtered) source before any changes occured.

There are alot of differences between the new pcihdr.h, and the old; but its from the same source. So its a good idea we're leaving it.

[johndrinkwater]

incorporates Korli's suggestion

[johndrinkwater]

​http://pciids.sourceforge.net/pci.db looks like a good candidate.

There is a problem though; this data doesnt supply short Vendor name, nor a separate chip/chipset field. Would a revised PCI_DEVTABLE & PCI_VENTABLE struct be ok? If not, should/could fields be duplicated into each?

Like: { 0x0675, 0x1700, "IS64PH ISDN Adapter", "IS64PH ISDN Adapter" }

[korli]

Sure. As of now, we only use :

• PCI_VENTABLE_LEN, PciVenTable[i].VenId, PciVenTable[i].VenFull
• PCI_DEVTABLE_LEN, PciDevTable[i].VenId, PciDevTable[i].DevId,

PciDevTable[i].ChipDesc

and maybe classe informations (bottom of pcihdr.h)

[korli]

pci.ids seems better than pci.db, because pci.db also contains non validated, and deleted data.

[johndrinkwater]

An awk script to handle pciids.sourceforge.net/pci.ids

[korli]

Tested: a problem appeared with " in strings. " should be escaped in device and vendor strings.

[korli]

Bugs again:

{ 0x10de, 0x01ec, "nForce2 Memory Controller 2"^@@,

{ 0x10ee, 0x0410, "Wildcard TE410P (2nd Gen)"^@@,

[johndrinkwater]

I'm afraid I dont see this problem: [john@ezri64 Desktop]$ awk --version GNU Awk 3.1.4 <snip>

{ 0x10de, 0x01eb, "nForce2 Memory Controller 1" }, { 0x10de, 0x01ec, "nForce2 Memory Controller 2" }, { 0x10de, 0x01ed, "nForce2 Memory Controller 3" },

I'm wondering if its to do with the amount of memory the list needs, I can probably fix that with a quick regig.

Could you tell me how long it takes to process?

[korli]

I integrated this "less memory hungry" version as it works very well (no bugs and fast) in revision 16080. I think code guidelines don t apply on generated code AFAIK. Thanks for this hard work.

[korli]

Still an error : pcihdr.h is used also by the pci bus manager. It makes use of Chip and VendorShort. I added them empty ... to fix the build. I'll investigate if they're useful at all.

[johndrinkwater]

I wonder what we're going to do for a source of PCI information, if we distrust pcidatabase, and require more information from pciids.

hmm :/

[if the pci bus manager requires this file as well, should we move it into a more relevant space, re: headers/private(?)]

[johndrinkwater]

Fixes the escapement problems

[johndrinkwater]

Less memory hungry

[korli]

Why did you reopen the bug ?

[johndrinkwater]

sorry, accidental.

[johndrinkwater]

Looked at a reworking of this script, after some errors on output

[korli]

taken into account in revision 16199. to be tested by Axel or Marcus

[johndrinkwater]

A new version, doesnt require pipe usage

[axeld]

This seems to work with the original R5 awk. BTW it might be a problem of Fran?ois' pipefs implementation, as that's what I'm using under R5.

[johndrinkwater]

Cleaner, nicer formatting, and w/ comments

[korli]

Committed in revision #16214, as before I added empty VenShort and Chip fields.