DragonFly kernel List (threaded) for 2006-04
pcidevs.h, is it worth it?
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. :)