meltin.net

lsvpd is a serviceability package written for Linux running on IBM pSeries® systems, although it also runs on other architectures with at least a Linux® 2.6 kernel. Developed as a look-alike for the AIX® tool of the same name, lsvpd includes a hardware inventory database, scanning components that populate the database, and a variety of query tools. The focus is on listing Vital Product Data (VPD) for components as part of hardware service calls - in such cases knowledge of model numbers, engineering versions of circuit boards, and microcode versions can be critical in determining the the correct fix for a problem. Use of a database, rather than querying hardware directly is an important requirement since it may not be possible to get required information from a faulty component.

Certain problems with the current version of lsvpd can't be reliably fixed without proper hotplug support. The current version of lsvpd for Linux is a combination of bash scripts and "helper programs" written in C. Therefore, due to the large number of processes that are spawned, it is unlikely to cope well with a large number of hotplug events in a short amount of time. A decision has been made to "migrate" the current implementation to C - the plan is to make the helper programs incrementally larger so they eventually replace the entire bash implementation. One feature of the current bash implementation is run-time loadable modules that can provide additional functionality depending on available system features, such as sysfs. Implementing this as elegantly in C will be interesting.

This paper discusses the above in a number of contexts, including:

• The need for a small, efficient hardware inventory system for Linux. Other systems, such as OpenPegasus, also do hardware inventory, and could use a lower-level implementation if it were available and suitable.
• The use of a hardware inventory system as part of a persistent device naming system. This would involve generalising something like the scsi_id program, but would use general VPD values for many different types of devices. A prototype has been demonstrated using the current implementation of lsvpd.
• The level of success migrating the current implementation to C. Some part of the migration will be complete by the time the paper is due.
• The trend towards writing system utilities in scripting languages. As a serviceability tool, lsvpd may be required to help diagnose problems when only a partial system is available - there may be no /usr filesystem.