HPI General FAQ - Management Instruments

Addressing Zero Fields/Areas within an IDR

Similarly, the specification states that "an Inventory Data Repository (IDR) is composed of a Repository Information Header and one or more Inventory Data Areas." (Again, see page 98). It appears that the IDR may be initially populated by starting off as a blank IDR, and then creating new areas, using saHpiIdrAreaAdd(). If this is the case, then it seems as though it would be valid for an IDR to contain zero areas, as well.

Answer:  You are correct in defining the appropriate mechanisms for adding areas and fields to IDRs. The statements on the bottom of page 98 are in error, and should read: "An Inventory Data Repository (IDR) is composed of a Repository Information Header and zero or more Inventory Data Areas. An Inventory Data Area is composed of an Area Header and zero or more Inventory Data Fields."

The HPI specification will be updated accordingly upon its next release.

In addition, the saHpiIdrAreaHeaderGet() function should return SA_ERR_HPI_NOT_PRESENT if the addressed IDR contains no Areas. And, the saHpiIdrFieldGet() function should return SA_ERR_HPI_NOT_PRESENT if the addressed IDA contains no Fields.

What is the purpose of the IsFru flag in the RDR entry?

The IsFru flag was introduced to describe a situation that occurs in representing certain system architectures. Figure 1 below depicts an example system that illustrates the use of the IsFru flag.

Figure 1: System with Alarm Module, Power Supply and Fan Tray

In this example system, there is a sensor located on a field replaceable unit (FRU) – the airflow sensor on the fan tray. This sensor is controlled and accessed from another FRU – via the alarm module. A sensor is also located on a fixed (non-field replaceable) unit – the voltage sensor on the power supply. It, too, is accessed and controlled by the alarm module.

The logical modeling data is depicted in Figure 2.

Figure 2: Logical Model of a System with Alarm Module, Power Supply and Fan Tray

In HPI, the RPT would contain entries for both the alarm module and the fan tray, as these are both FRUs within the system. The FRUs are normally modeled as Resources, because a Resource can manage a Hot Swap State Machine, necessary for a FRU. There would be no RPT entry for the power supply, as it is not a FRU, nor does it provide a management access point for the system.

The alarm module would contain an RDR repository with entries for the fan tray sensor and for the power supply sensor. This is because the alarm module provides management access to these sensors, even though the sensors are detecting conditions about entities other than the alarm module. The entity path allows an HPI User to determine what entity a particular sensor is monitoring.

Note the RDR Repositories are static.

When discovering the system, an HPI User is expected to create managed objects for the entities found in the RPT. An HPI User is also expected to create managed objects for entities found when traversing the RDRs.

An HPI User needs to rely on both the RPT and RDRs to find all of the entities of the system. As in the example system shown above, the power supply is not represented in the RPT, and is only found via examining the RDRs.

The difficulty comes in when an entry in the RDR Repository is referencing a FRU, which may or may not be present in the system. This is illustrated in Figure 3.

Figure 3: System with Alarm Module and Power Supply

In Figure 3, the fan tray is absent from the system, and its entry is not present in the RPT. But, because the RDR Repository for the alarm module is static, the fan tray’s sensor is still represented there.

Now, if an HPI User were to apply the same algorithm as used for the power supply – that is, were they to create a new managed object based on the fan tray entity path as discovered from the RDR entry – they’d erroneously create a managed object for something that isn’t part of the system.

The IsFru flag is meant to alert an HPI User to this condition. That is, if the RDR entry indicates that it is representing an entity that is a FRU, the RPT should be consulted to determine if the entity is present in the system. Else the entity is not a FRU, and upon discovering a new entity path in the RDR repository, that entity should be added to the list of managed objects in the system.

Given this intended usage of the IsFru flag, the recommended discovery procedure for HPI Users is as follows:

1. Scan all RPTs, adding entities found to the system model

2. Scan all RDRs, adding additional entities found there UNLESS they are marked with the IsFru flag. The rationale for not including these is that they should be reflected in RPT entries if they are present in the system, so they will be discovered in step 1.

2a. While scanning for IsFru RDRs and their entities; it may be a good idea for an HPI User to cache the RDR entries for non-existent IsFru entities, to save a full traversal of the RPTs and RDRs whenever a new FRU is inserted in the future.

Though the example above describes the use of the IsFru flag for sensors, its use is generally applicable to all management instruments.

As a final note, when a management instrument for a non-existent FRU entity is accessed, the SA_ERR_HPI_ENTITY_NOT_PRESENT return code is returned.