pcidevs.h, is it worth it?

[Sascha Wildner <saw@xxxxxxxxx>]

Hi,

the sys/bus/pci/pcidevs.h header file is currently being used by 7 
drivers only: acx, an, bfe, bge, tx, vx and (partially, I think) bktr.

I've begun converting the rest of our drivers to use it. However, after 
having converted around 20 of them, I'm starting to wonder if it's 
really worth the effort.

My main gripe is that even among the BSDs the pcidevs files differ. For 
example in card descriptions (which alone is not so bad because they are 
converted to comments only) and vendor names. The latter is already more 
of an issue because the vendor name is part of the ID's symbolic name 
that's later used in the source code.

The worst issue in my opinion is that among NetBSD, OpenBSD and 
DragonFly the same names are sometimes used for different IDs. For 
example the name "PRO_100_VE_5" (Intel card) is 0x1068 in NetBSD, 0x1050 
in OpenBSD and 0x1064 in DragonFly. Think about one committer syncing a 
couple of IDs from OpenBSD and another bringing in a new driver for 
those devices from NetBSD at a later point in time. He looks at pcidevs 
and sees that the device names are already in but fails to notice that 
the ID is different.

Of course, confusion in PCI land is nothing new and my example 
admittedly is a bit constructed (all those IDs use are for the same 
driver), but I'm just wondering if we should adopt the confusion by 
using pcidevs.h for all drivers.

Where's the gain in using symbolic names that contain the vendor and 
product name? As I feel right now, just hardcoding the 32 bit values 
into all drivers would at least be the most unambiguous way. What would 
be wrong about that? There's descriptions naming the vendor and product 
anyway in the drivers and as a reference we always have 
/usr/share/misc/pci_vendor (the much larger database for pciconf).

Comments appreciated. :)

Sascha

--
http://yoyodyne.ath.cx