Method, system, and software for determining platform management functionality

TECHNICAL FIELD

The present disclosure relates generally to platform management interfaces, and more particularly to determining which platform management options are supported by a particular implementation of a platform management interface.

BACKGROUND

As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.

Many information handling systems provide platform management subsystems capable of monitoring and controlling, either locally or remotely, various hardware subsystems and functions such as voltages, temperatures, fan speeds, and the like. These platform management subsystems are generally accessed through an Intelligent Platform Management Interface (IPMI), which is a standard interface to the platform management subsystem.

Although IPMI defines a standard interface for platform management subsystems, IPMI allows vendors to support different subsets of parameters for various commands. Additionally, the IPMI specification defines some commands as optional, and not all vendors provide platform management subsystems that support the entire universe of optional commands. These variations in IPMI implementation pose challenges to the interoperability of system management software, at least in part because issuing an unsupported command or command option to a platform management subsystem can cause the platform management subsystem to stop responding, or to respond in an unexpected or undesired manner.

The IPMI 1.5 specification allows a user to determine if a command is supported by a platform management system by issuing the command and checking the status returned from firmware. The IPMI 2.0 specification provides a command that allows a user to determine if other commands are supported, without requiring the other commands to be issued.

Some software accounts for variations in implementation of supported commands and parameters across different platforms by maintaining a list of options supported by particular system ID's. Using the system ID in this way requires software updates whenever support for a new platform is added, or when command implementation is changed on a platform.

SUMMARY

In accordance with teachings of the present disclosure, a system, method and software are described for determining the functionality, e.g. supported commands and command parameters, of a platform management subsystem, and providing that information to software applications such as instrumentation level and presentation layer applications. By providing information about platform management functionality, to software applications, the software can intelligently determine which platform management options to expose to a system's user. Furthermore, the software can use the information to prevent an unsupported command or command option from being issued to a platform management subsystem.

According to at least one embodiment, a single implementation of system management software, particularly the instrumentation software and related graphical user interface (GUI) framework, can be applied to different platforms, from different vendors, implementing different IPMI versions. The flexibility of such an embodiment may provide reduced software development cycles and reduce a product's Time to Market.

A method according to an embodiment of the present disclosure includes determining whether functionality associated with respective commands is supported by the platform management subsystem, and storing the results of the determination in a file accessible to at least presentation layer applications. The functionality so determined may include identifying supported commands and command parameters. According to at least one embodiment, the method attempts to set a command parameter to each of a plurality of parameter values, and determines if the respective parameter values are supported based on a completion code provided by the platform management subsystem.

Supported commands may be determined, according to various embodiments, by commanding the platform management subsystem to identify supported commands, or by issuing a command and evaluating the completion code returned. Some embodiments create or modify a file to include information identifying supported commands or command codes. This file can be accessed by software to provide improved user interaction, and to prevent issuing unsupported commands or setting unsupported command parameters.

In one form, a method according to an embodiment of the disclosure is embodied as a program of executable instructions encoded in a computer readable medium. A program of instructions according to at least one such embodiment includes at least one instruction to determine whether functionality associated with respective commands is supported by a platform management subsystem, and at least one instruction to store results of the determination in a file accessible to software.

In yet another embodiment, an information handling system is provided. The information handling system includes a platform management subsystem, a processor and associated memory, and a program of instructions to be stored in the memory and executed by the processor. The program of instructions implements a method that includes determining whether functionality associated with respective commands is supported by the platform management subsystem, and storing results of the determination in a file accessible to at least presentation layer applications.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the present embodiments and advantages thereof may be acquired by referring to the following description taken in conjunction with the accompanying drawings, in which like reference numbers indicate like features, and wherein:

<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram illustrating an information handling system including an Intelligent Platform Management subsystem according to an embodiment of the present disclosure.

<figref idref="DRAWINGS">FIG. 2</figref> is a diagram illustrating the relationship of an IPMI subsystem, software applications, and a profiling program or function according to an embodiment of the present disclosure.

<figref idref="DRAWINGS">FIG. 3</figref> is a flow diagram illustrating a method of profiling command parameters supported by a platform management subsystem according to an embodiment of the present invention.

<figref idref="DRAWINGS">FIG. 4</figref> is a flow diagram illustrating a method of profiling supported commands according to an embodiment of the present invention.

DETAILED DESCRIPTION

Preferred embodiments and their advantages are best understood by reference to <figref idref="DRAWINGS">FIGS. 1 through 4</figref>, wherein like numbers are used to indicate like and corresponding parts.

For purposes of this disclosure, an information handling system may include any instrumentality or aggregate of instrumentalities operable to compute, classify, process, transmit, receive, retrieve, originate, switch, store, display, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for business, scientific, control, or other purposes. For example, an information handling system may be a personal computer, a network storage device, or any other suitable device and may vary in size, shape, performance, functionality, and price. The information handling system may include random access memory (RAM), one or more processing resources such as a central processing unit (CPU) or hardware or software control logic, ROM, and/or other types of nonvolatile memory. Additional components of the information handling system may include one or more disk drives, one or more network ports for communicating with external devices as well as various input and output (I/O) devices, such as a keyboard, a mouse, and a video display. The information handling system may also include one or more buses operable to transmit communications between the various hardware components.

Referring first to <figref idref="DRAWINGS">FIG. 1</figref>, one such information handling system will be discussed according to an embodiment of the present disclosure. Information handling system <b>100</b> includes motherboard <b>110</b>, chassis board <b>120</b>, redundant power board <b>130</b>, modulator demodulator (modem) <b>141</b>, peripheral component interconnect (PCI) card <b>143</b>, remote management card <b>115</b>, and local area network (LAN) <b>147</b>. Information handling system <b>100</b> may also include various interface devices, storage devices, and the like, which are not illustrated.

Motherboard <b>110</b> includes processor board <b>112</b>, memory board <b>114</b>, system interface <b>116</b>, LAN controller <b>151</b>, non-volatile storage <b>153</b>, and baseboard management controller (BMC) <b>155</b>. Motherboard <b>110</b> also includes various connectors, e.g. LAN connector <b>157</b>, serial connector <b>159</b>, PCI connectors <b>161</b>, intelligent platform management bus (IPMB) connector <b>163</b>, serial port sharing circuitry <b>165</b>, and various sensors and controls <b>167</b>.

BMC <b>155</b> is connected to the various illustrated devices via management busses. BMC <b>155</b> is connected, for example, to PCI card <b>143</b> by PCI management bus <b>161</b>; to chassis board <b>120</b>, remote management card <b>115</b>, and redundant power supply board <b>130</b> by IPMB <b>172</b>; to memory board <b>114</b> and processor board <b>112</b> by private management busses <b>174</b>.

In at least one embodiment, BMC <b>155</b> receives sensor information associated with processor voltages, fan speed, temperature, etc., from sensors and control <b>167</b>, chassis board <b>120</b>, and redundant power board <b>130</b>, and provides that information to a user. BMC <b>155</b> may provide the information to the user via remote management card <b>115</b>, system bus <b>194</b>, modem <b>141</b>, serial controller <b>118</b>, or LAN <b>147</b> using either in-band or out of band communications. Information received via system bus <b>194</b>, LAN <b>147</b>, modem <b>141</b>, or remote management card <b>115</b> may be used to change voltages and fan speeds, or otherwise control PCI card <b>143</b>, chassis board <b>120</b>, redundant power board <b>130</b>, processor board <b>112</b>, etc.

Consider the following example, in which the redundant power board <b>130</b> is to be brought on-line due to fluctuations in processor voltage. BMC <b>155</b> receives voltage readings from sensors and control <b>167</b> indicating that the processor voltage is not being properly regulated. The readings, or alarms based on the readings in some embodiments, are provided to a remote monitoring system using remote management card <b>115</b>.

In one embodiment, the remote system (not illustrated) presents the user with a list of supported commands and command parameters associated with control of redundant power board <b>130</b>. The user may select an appropriate command, and the remote system sends the selected command back to BMC <b>155</b>. BMC <b>155</b> executes the selected command by taking the primary power supply (not illustrated) off-line, and bringing the redundant power board on-line in its place.

In at least one embodiment, communication between the BMC, which is part of an intelligent platform management system, and the remote server, is controlled by software that provides an interface between the hardware/firmware level and higher level, software applications.

Referring next to <figref idref="DRAWINGS">FIG. 2</figref>, Profiling Software/Function <b>240</b> will be discussed according to an embodiment of the present disclosure. The dashed line <b>210</b> represents the interface between software <b>260</b> and hardware <b>250</b>.

Hardware <b>250</b> may include a baseboard management controller (BMC) <b>202</b>, and a hardware/firmware interface such as IPMI H/W interface <b>204</b>. Software <b>260</b> may include IMPI I/F Code <b>212</b>, instrumentation code <b>217</b>, service provider (SP) interface <b>219</b>, service provider software <b>221</b>, in-band remote access software <b>223</b>, and management applications <b>225</b>.

In one embodiment, as the first layer between IPMI H/W interface <b>204</b> and other software applications IPMI I/F code <b>212</b> abstracts data from Hardware <b>250</b>, maps the abstractions to a data model that is understandable by the higher level software, and converts requests from software <b>260</b> to hardware <b>250</b>. In at least one embodiment, a system employing IPMI I/F code <b>212</b> provides support of IPMI version 1.5 and above using the same code base, regardless of the platform vendor.

At least one embodiment of the present disclosure includes a profiling software/function <b>240</b> that executes upon initial installation of the program, at boot time, periodically, upon installation of a program update, or at other scheduled or unscheduled times as deemed appropriate consistent with the teachings set forth herein. In some embodiments, the profiling software function <b>240</b> is installed and executed independent of IPMI I/F code <b>212</b>, while other embodiments incorporate the functions of profiling software/function <b>240</b> into IMPI I/F code <b>212</b>.

According to at least one embodiment, the profiling software/function <b>240</b> determines which command and parameter options are supported by the hardware. In some embodiments, the profiling program generates one or more files that include information identifying the supported IPMI commands and/or parameters. In other embodiments, one or more pre-existing files are modified to include this information. Regardless of whether the files are generated originally by the profiling program, or are modified by the profiling program, the files including information about which commands and profiles are supported are made available to the software applications such as instrumentation code <b>217</b> and management applications <b>225</b>. The file may be used in some embodiments to provide improved usability and/or prevent a user from inadvertently setting an unsupported command/parameter combination to firmware.

Providing awareness of platform management functionality to higher level software may be advantageous, for example, where the supported options for obtaining an IP address source differ from one manufacturer of platform management systems to another. In one instance, a first manufacturer may support obtaining an Internet protocol (IP) address through DHCP, but not support configuring an IP address using a system's basic input output system (BIOS). A second manufacturer may not support obtaining an IP address through DHCP, but may support configuring the IP address through BIOS. Consider also that although five different baud rates (<b>9600</b>, <b>19200</b>, etc) may be supported in a particular implementation of IPMI, a given platform may only support four of the five baud rates.

Additionally, some versions of the IPMI specification provide for optional commands, such as the GetAuxiliaryLogStatus command, or original equipment manufacturer (OEM) defined commands. Some vendors may choose to support a particular optional command, or to implement a custom OEM command, while others do not.

Referring next to <figref idref="DRAWINGS">FIG. 3</figref>, a method <b>300</b> of profiling supported command parameters to determine which command parameters are supported by a particular platform will be discussed according to an embodiment of the present disclosure. Execution of method <b>300</b> begins at <b>310</b>. Method <b>300</b> may be implemented as a standalone capabilities profile program or function according to an embodiment of the present disclosure. Method <b>300</b> may also be implemented as part of IPMI interface (I/F) code (see <figref idref="DRAWINGS">FIG. 2</figref>), as firmware executed under control of a BIOS, as a part of an operating system, or the like. In at least one embodiment, method <b>300</b> is performed upon initial power-up of a system to determine variations in command options supported by the system. In other embodiments, method <b>300</b> may be performed during initial system configuration during manufacturing or after hardware replacement.

The method determines which command to profile at <b>320</b>, based on data from an input configuration file, e.g. an input.ini or an input.XML file. In at least one embodiment, the configuration file includes commands supported by the system on which method <b>300</b> is being implemented and parameters associated with those commands. Content representative of a configuration file according to an embodiment of the present disclosure is presented below: <tables id="TABLE-US-00001" num="1"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="182PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>#// ---- Set cmds to profile ----</entry></row><row><entry /><entry>[BMC Command Section]</entry></row><row><entry /><entry>bmccmd.0x00=SetLANConfig</entry></row><row><entry /><entry>bmccmd.0x01=SetSerialConfig</entry></row><row><entry /><entry>bmccmd.0x02=SetSOLConfig</entry></row><row><entry /><entry>bmccmd.0x03=SetPEFConfig</entry></row><row><entry /><entry>bmccmd.0x04=...</entry></row><row><entry /><entry>#// ---- LAN config param to profile ----</entry></row><row><entry /><entry>[SetLANConfig]</entry></row><row><entry /><entry>NetFnLUN=0x18</entry></row><row><entry /><entry>CMD=0x01</entry></row><row><entry /><entry>bmcattr.0x00=IPAddrSrc</entry></row><row><entry /><entry>bmcattr.0x01=...</entry></row><row><entry /><entry>[GetLANConfig]</entry></row><row><entry /><entry>NetFnLUN=0x18</entry></row><row><entry /><entry>CMD=0x02</entry></row><row><entry /><entry>#// ---- Info for IP address source ----</entry></row><row><entry /><entry>[IPAddrSrc]</entry></row><row><entry /><entry>dataattrib=EMPLANConfigObj.IPAddrSource</entry></row><row><entry /><entry>channel=LAN</entry></row><row><entry /><entry>getcmd= GetLANConfig</entry></row><row><entry /><entry>getdatalen=4</entry></row><row><entry /><entry>getreqdata=channel,0x04,0x00,0x00</entry></row><row><entry /><entry>setopt.0x01= IPAddrSrc.static</entry></row><row><entry /><entry>setopt.0x02= IPAddrSrc.DHCP</entry></row><row><entry /><entry>setopt.0x03= IPAddrSrc.BIOS</entry></row><row><entry /><entry>[IPAddrSrc.static]</entry></row><row><entry /><entry>setdatalen=3</entry></row><row><entry /><entry>setreqdata=channel,0x04,0x01</entry></row><row><entry /><entry>ccode=0xCC</entry></row><row><entry /><entry>sptvalue=BIT[1]</entry></row><row><entry /><entry>[IPAddrSrc.DHCP]</entry></row><row><entry /><entry>setdatalen=3</entry></row><row><entry /><entry>setreqdata=channel,0x04,0x02</entry></row><row><entry /><entry>ccode=0xCC</entry></row><row><entry /><entry>sptvalue=BIT[2]</entry></row><row><entry /><entry>[IPAddrSrc.BIOS]</entry></row><row><entry /><entry>setdatalen=3</entry></row><row><entry /><entry>setreqdata=channel,0x04,0x03</entry></row><row><entry /><entry>ccode=0xCC</entry></row><row><entry /><entry>sptvalue=BIT[3]</entry></row><row><entry /><entry>#// ---- Serial config param to profile ----</entry></row><row><entry /><entry>[SetSerialConfig]</entry></row><row><entry /><entry>NetFnLUN=0x18</entry></row><row><entry /><entry>CMD=0x10</entry></row><row><entry /><entry>attrcfg.0x00=ConnMode</entry></row><row><entry /><entry>attrcfg.0x01=...</entry></row><row><entry /><entry>[GetSerialConfig]</entry></row><row><entry /><entry>NetFnLUN=0x18</entry></row><row><entry /><entry>CMD=0x11</entry></row><row><entry /><entry>#// ---- Info for Connection Mode ----</entry></row><row><entry /><entry>[ConnMode]</entry></row><row><entry /><entry>dataattrib=EMPSerialConfigObj.connectionMode</entry></row><row><entry /><entry>channel=Serial</entry></row><row><entry /><entry>getcmd=GetSerialConfig</entry></row><row><entry /><entry>getdatalen=4</entry></row><row><entry /><entry>getreqdata=channel,0x03,0x00,0x00</entry></row><row><entry /><entry>setopt.0x01= ConnMode.modem_basic</entry></row><row><entry /><entry>setopt.0x02= ConnMode.modem_terminal</entry></row><row><entry /><entry>setopt.0x03= ConnMode.direct_basic</entry></row><row><entry /><entry>[ConnMode.modem_basic]</entry></row><row><entry /><entry>setdatalen=3</entry></row><row><entry /><entry>setreqdata=channel,0x03,0x01</entry></row><row><entry /><entry>ccode=0xCC</entry></row><row><entry /><entry>sptvalue=BIT[0]</entry></row><row><entry /><entry>[ConnMode.modem_terminal]</entry></row><row><entry /><entry>setdatalen=3</entry></row><row><entry /><entry>setreqdata=channel,0x03,0x04</entry></row><row><entry /><entry>ccode=0xCC</entry></row><row><entry /><entry>sptvalue=BIT[2]</entry></row><row><entry /><entry>[ConnMode.direct_basic]</entry></row><row><entry /><entry>setdatalen=3</entry></row><row><entry /><entry>setreqdata=channel,0x03,0x81</entry></row><row><entry /><entry>ccode=0xCC</entry></row><row><entry /><entry>sptvalue=BIT[3]</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

So, for example, for an input configuration file including the above information, the BMC command SetLANConfig may be selected for profiling at <b>320</b>.

The method proceeds to <b>330</b>, where one of the parameters associated with the selected command, SetLANConfig in the present example, is chosen for profiling. Assuming that none of the parameters associated with the BMC command SetLANConfig command have been previously profiled, at least one embodiment of method <b>300</b> may select the BMC attribute IPAddrSrc for profiling.

The current value of the selected command parameter, e.g. IPAddrSrc, is read from firmware at <b>340</b>, and stored for later use. The method then proceeds to <b>350</b>, where a parameter value to be profiled is read from the input configuration file. At <b>360</b> the method sets the parameter to the value obtained at <b>350</b> and issues the selected command with the newly set parameter value. Issuing the command will result in the BMC returning a completion code, which is used to determine whether the parameter is supported by the system. The result, e.g. whether or not the parameter is supported, is written to an output file, and the method returns to <b>350</b> to evaluate the next value of the parameter.

In at least one embodiment, once all of the parameter values for a particular command have been profiled, the method proceeds to <b>370</b>. At <b>370</b> the parameter is returned to its initial value, which was read from firmware at <b>340</b>. In this manner, method <b>300</b> can avoid inadvertently leaving a parameter value set to an unsupported value.

After setting the parameter value to its original state, method <b>300</b> loops back to <b>330</b>, and the next parameter is chosen for profiling. The method determines, for each possible value of the newly selected parameter, whether the value is supported, and writes the results to the output file in the manner previously discussed.

Once all parameters for a particular command have been profiled, the method returns to <b>320</b> to read the next command to be profiled. Method <b>300</b> continues in this manner until the commands, parameters, and values identified in the input configuration file have been profiled.

Consider the following example using an input configuration file as discussed above. Assume that the SetLANConfig is the command selected at <b>320</b>, and that the IPAddrSrc parameter is selected at <b>330</b>. The method <b>300</b> will issue the SetLANConfig command with the IPAddrSrc parameter set to static, and receive a completion code from the platform management subsystem indicating whether the command executed successfully. If the completion code indicates that the command executed successfully, an output file will be generated and/or updated to reflect that the IPAddrSrc parameter supports a value of “static.” Method <b>300</b> will then set the IPAddrSrc to DHCP and BIOS, in turn, and update the output file to reflect whether the respective values are supported.

Method <b>300</b> may then select the SetSerialConfig command to be profiled, and select the ConnMode parameter as the first parameter to profile. The SetSerialConfig command will be issued with the ConnMode set to Conmodem_basic, modem_terminal, and direct_basic in turn, using the completion code returned by the platform management subsystem to determine if the respective parameters are supported. The results can be stored in the output file, and the method will continue to profile remaining commands and parameters in the input configuration file.

In at least one embodiment, the output file e.g. output.xml, can be used by other applications, such as presentation layer applications, to determine supported options, or by instrumentation software to populate attributes for capabilities, which can then be used by higher level applications. An output file according to various embodiments of the present invention may also be used by other applications consistent with the teachings set forth herein.

An example of information included in an output file according to an embodiment of the present invention is presented below. Continuing with the previous example, the output file below illustrates that values of “static” and “DHCP” are supported for the parameter IPAddrSrc, but the value “BIOS” is unsupported. Similarly, the value “direct_basic” is supported for the parameter ConnMode, but the values “modem_basic” and “modem_terminal” are not. <tables id="TABLE-US-00002" num="2"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="21PT" align="left" /><colspec colname="1" colwidth="196PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>&lt;EMPLANConfigObj&gt;</entry></row><row><entry /><entry>  &lt;IPAddrSrce&gt;</entry></row><row><entry /><entry>    &lt;static&gt;true&lt;/static&gt;</entry></row><row><entry /><entry>    &lt;DHCP&gt;true&lt;/DHCP&gt;</entry></row><row><entry /><entry>    &lt;BIOS&gt;false&lt;/BIOS&gt;</entry></row><row><entry /><entry>  &lt;/IPAddrSource&gt;</entry></row><row><entry /><entry>&lt;/EMPLANConfigObj&gt;</entry></row><row><entry /><entry>&lt;EMPSerialConfigObj&gt;</entry></row><row><entry /><entry>  &lt;connectionMode&gt;</entry></row><row><entry /><entry>    &lt;modem_basic&gt;false&lt;/modem_basic&gt;</entry></row><row><entry /><entry>    &lt;modem_terminal&gt;false&lt;/modem_terminal&gt;</entry></row><row><entry /><entry>    &lt;direct_basic&gt;true&lt;/direct_basic&gt;</entry></row><row><entry /><entry>  &lt;/connectionMode &gt;</entry></row><row><entry /><entry>&lt;/EMPSerialConfigObj &gt;</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

It will be appreciated that although only two commonly used BMC configuration commands are discussed above, with only one parameter for each, the same principles apply equally well to the fairly large number of command/parameter/value combinations that may be profiled. At least one embodiment of method <b>300</b> can save a linearly increased amount of code work over requiring each command/parameter/value combination to be specifically coded in a program. When adding new combinations according to at least one such embodiment, the input configuration file is updated, but the binary program does not need to be updated.

Referring next to <figref idref="DRAWINGS">FIG. 4</figref>, a method <b>400</b> for determining if commands are supported by a platform will be discussed according to an embodiment of the present disclosure. Recall that the illustrated embodiment of method <b>300</b> (<figref idref="DRAWINGS">FIG. 3</figref>) may be used to determine which command parameters are supported by a particular platform. Method <b>400</b>, similarly, may be used to determine which commands are supported by a platform. Used in conjunction, methods <b>300</b> and <b>400</b> may be used to profile supported BMC commands and command parameters.

Execution of method <b>400</b> begins at <b>410</b>. Method <b>400</b> may be implemented as a commands profile program or function according to an embodiment of the present disclosure, and may be implemented as part of an IPMI I/F code (see <figref idref="DRAWINGS">FIG. 2</figref>), as firmware executed under control of a BIOS, as a standalone program executed under control of a system level operating system, or the like. In at least one embodiment, method <b>400</b> is performed upon initial power-up of a system to determine variations in command options supported by the system.

At <b>420</b>, method <b>400</b> determines whether the platform on which method <b>400</b> is being performed is IPMI version 1.5 or 2.0. It should be noted that although method <b>400</b> is discussed in terms of IPMI versions 1.5 and 2.0, various methods may be implemented with other IPMI versions, or with other suitable platform management interface.

For IPMI 1.5 platforms, the method proceeds to <b>431</b>, and obtains a command to be evaluated. In at least one embodiment, the command to be evaluated is obtained by reading the command from a command configuration file, e.g. command.ini or command.XML. An example of information that may be included in a command configuration file according to an embodiment of the invention is presented below. Note that the information shown is representative of a command configuration file prior to being modified by method <b>400</b>. <tables id="TABLE-US-00003" num="3"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="21PT" align="left" /><colspec colname="1" colwidth="196PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>#// ---- cmds to profile ----</entry></row><row><entry /><entry>[BMC Command Section]</entry></row><row><entry /><entry>bmccmd.0x00=GetAuxiliaryLogStatus</entry></row><row><entry /><entry>bmccmd.0x01=RestoreDefaults</entry></row><row><entry /><entry>bmccmd.0x02=...</entry></row><row><entry /><entry>#// ---- Info for Get Auxiliary Log Status ----</entry></row><row><entry /><entry>[GetAuxiliaryLogStatus]</entry></row><row><entry /><entry>IgnoreProlileOn=comma_delimited_list_of_system_IDs</entry></row><row><entry /><entry>ForceSupportOn=comma_delimited_list_of_system_IDs</entry></row><row><entry /><entry>Channel=IPMB</entry></row><row><entry /><entry>NetFnLUN=0x28</entry></row><row><entry /><entry>CMD=0x5A</entry></row><row><entry /><entry>ReqDataLen=1</entry></row><row><entry /><entry>ReqData=1</entry></row><row><entry /><entry>CCode=0xC1</entry></row><row><entry /><entry>SupportedDefault=True</entry></row><row><entry /><entry>SupportedOutput=</entry></row><row><entry /><entry>#// ---- Info for Restore Defaults ----</entry></row><row><entry /><entry>[RestoreDefaults]</entry></row><row><entry /><entry>IgnoreProlileOn=comma_delimited_list_of_system_IDs</entry></row><row><entry /><entry>ForceSupportOn=comma_delimited_list_of_system_IDs</entry></row><row><entry /><entry>Channel=IPMB</entry></row><row><entry /><entry>NetFnLUN=0xF8</entry></row><row><entry /><entry>CMD=0x0D</entry></row><row><entry /><entry>ReqDataLen=1</entry></row><row><entry /><entry>ReqData=0</entry></row><row><entry /><entry>CCode=0xC1</entry></row><row><entry /><entry>SupportedDefault=False</entry></row><row><entry /><entry>SupportedOutput=</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Method <b>400</b> proceeds to <b>433</b>, where the system ID is used to determine if the command should be profiled, or if the command should be ignored. According to at least one embodiment, if the command is not to be profiled the command's default value is read from the configuration file at <b>435</b> as the final value. The final value may then be used at <b>441</b> to update an attribute of the command, e.g. SupportedOutput, in the command configuration file to indicate whether the command it is supported or not. After updating the command configuration file at <b>441</b>, method <b>400</b> may return to <b>431</b> to determine if additional commands are supported.

If method <b>400</b> determines at <b>433</b> that the command should be profiled, the method proceeds to <b>437</b>, where the command is issued to the platform management system. In at least one embodiment, the command is issued using the channel, NetFnLUN, command, data length and data provided by the command configuration file.

In the illustrated embodiment, platform management firmware will return a completion code indicating whether the issued command successfully completed. Method <b>400</b> can use the completion code at <b>439</b> to determine whether the issued command is supported by the platform. If the completion code from firmware indicates that the command is supported on this platform, the method proceeds to <b>441</b> where the command configuration file is updated accordingly. After updating the command configuration file at <b>441</b>, method <b>400</b> may return to <b>431</b> to determine if additional commands are supported.

An example of information included in a command configuration file that has been updated according to method <b>400</b> is presented below. Note that the command configuration file shown below indicates that the GetAuxiliaryLogStatus command is not supported. <tables id="TABLE-US-00004" num="4"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="21PT" align="left" /><colspec colname="1" colwidth="196PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>#// ---- cmds to profile ----</entry></row><row><entry /><entry>[BMC Command Section]</entry></row><row><entry /><entry>bmccmd.0x00=GetAuxiliaryLogStatus</entry></row><row><entry /><entry>bmccmd.0x01=RestoreDefaults</entry></row><row><entry /><entry>bmccmd.0x02=...</entry></row><row><entry /><entry>#// ---- Info for Get Auxiliary Log Status ----</entry></row><row><entry /><entry>[GetAuxiliaryLogStatus]</entry></row><row><entry /><entry>IgnoreProlileOn=comma_delimited_list_of_system_IDs</entry></row><row><entry /><entry>ForceSupportOn=comma_delimited_list_of_system_IDs</entry></row><row><entry /><entry>Channel=IPMB</entry></row><row><entry /><entry>NetFnLUN=0x28</entry></row><row><entry /><entry>CMD=0x5A</entry></row><row><entry /><entry>ReqDataLen=1</entry></row><row><entry /><entry>ReqData=1</entry></row><row><entry /><entry>CCode=0xC1</entry></row><row><entry /><entry>SupportedDefault=True</entry></row><row><entry /><entry>SupportedOutput=False</entry></row><row><entry /><entry>#// ---- Info for Restore Defaults ----</entry></row><row><entry /><entry>[RestoreDefaults]</entry></row><row><entry /><entry>IgnoreProlileOn=comma_delimited_list_of_system_IDs</entry></row><row><entry /><entry>ForceSupportOn=comma_delimited_list_of_system_IDs</entry></row><row><entry /><entry>Channel=IPMB</entry></row><row><entry /><entry>NetFnLUN=0xF8</entry></row><row><entry /><entry>CMD=0x0D</entry></row><row><entry /><entry>ReqDataLen=1</entry></row><row><entry /><entry>ReqData=0</entry></row><row><entry /><entry>CCode=0xC1</entry></row><row><entry /><entry>SupportedDefault=False</entry></row><row><entry /><entry>SupportedOutput=True</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Still referring to <figref idref="DRAWINGS">FIG. 4</figref>, for platforms using IPMI 2.0, at least one embodiment of method <b>400</b> proceeds from 420 to 451, where it issues the GetCommandSupport command for each combination of channel, NetFn and LUN. The GetCommandSupport command causes the platform management system to return bit values for commands 00h through 7Fh or 80h through FFh. For each command, the program looks for a matching channel, NetFnLUN and command in the command configuration file at <b>453</b>.

If no match is found, the program will try next command. If a match is found at <b>453</b>, method <b>400</b> proceeds to <b>455</b>, and uses the system ID to determine if profiling of this command on should be ignored. If <b>455</b> determines that the command should be ignored, method <b>400</b> proceeds to <b>459</b>, where the default value of the command is obtained, according to at least one embodiment, from the command configuration file. The method then proceeds to <b>461</b>, where an attribute of the command, e.g. SupportedOutput, in the configuration file is updated to indicate whether the command is supported or not If the method determines at <b>455</b> that the command should not be ignored, at least one embodiment checks the bit value returned for the command in response to the GetCommandSupport command to ensure that the command is supported on the system. If the command is supported on this platform, the method proceeds to <b>461</b> where the command configuration file is updated accordingly. After updating the command configuration file at <b>461</b>, method <b>400</b> may return to <b>453</b> or <b>451</b> to evaluate support for other commands.

It should be appreciated that the methods described above, although illustrated and discussed as performing particular tasks in a particular order, may be implemented in various ways involving additional or fewer actions, or actions performed in an order different than the order discussed.

Implementing various embodiments of the above methods, or combinations of the above methods, may provide a way to turn off profiling of a command based on system ID, which can be useful if executing a command on a particular system can cause harm to the system. Various embodiments also allow the decision to override an otherwise unsupported command. Furthermore, at least one embodiment can be implemented using a configuration file, and does not require that the binary code be revised.

Although the disclosed embodiments have been described in detail, it should be understood that various changes, substitutions and alterations can be made to the embodiments without departing from their spirit and scope.