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_strings.h>, meaning your source code must include this file using #include <pci/pci_strings.h> to use the API.

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 pcidatabase.com, but you can edit this file to add, delete, and modify the strings as required. The database file is specified with the PCI_STRINGS_FILE environment variable. If this variable is not set, the default file, /etc/system/config/pci/pcidatabase.com-tab_delimited.txt, 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:

• It leverages an existing database of vendor and device strings.
• The information isn't hard-coded into any code.
• Customers can update or edit the file as they wish.
• Community updates can be easily provided to all through forum posts, etc.
• For systems with no slots, the file can be edited down to include only the devices known to exist on the particular hardware, thus reducing the overhead of processing a large file.

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.