The “Strings” module

One of the goals of the PCI server design is to eliminate the dependency of the code base on external factors such as vendor and device names and the addition of new devices, etc. To accomplish this, the PCI server and library don't contain any textual information related to vendors, devices, or class codes. This information is provided in the form of #defines (see <pci/pci_id.h> and <pci/pci_ccode.h>) based on PCISIG assignments so that they're available to driver software when calling pci_device_find(), but the text associated with these definitions isn't.

Instead, a strings module that contains APIs to access this information is available for linking tools and utilities against, as it's really only this software that needs to display such human-readable information. The strings module is the only module that software will link against and hence create a version dependency.

API definitions for the strings module are contained in <pci/pci_string.h>.

The class code strings within the strings module are fixed and as defined by the PCISIG. They correspond to the class codes defined in <pci/pci_ccode.h>.

The vendor and device strings are obtained by parsing a strings database file contained in ${QNX_TARGET}/etc/system/config/pci/ on your development host, and normally installed in /etc/system/config/pci/ on your target. The current version of the strings module expects a tab-delimited file. The original source of this file was obtained from, but you can edit to add, delete, and modify the strings as required. The database file is specified with the PCI_STRINGS_FILE environment variable. If not set, the default file, /etc/system/config/pci/, is used. This allows users to freely edit the database file to list only known devices or to add custom ones without any PCI server changes.

The benefits include:

Because the strings module is a separate and independent module, the format of the database file can change in the future without impacting other PCI server subsystems.