diff options
| -rw-r--r-- | xyz/openbmc_project/Common/Callout/README.md | 16 |
1 files changed, 8 insertions, 8 deletions
diff --git a/xyz/openbmc_project/Common/Callout/README.md b/xyz/openbmc_project/Common/Callout/README.md index 0636e81..9ba0ef7 100644 --- a/xyz/openbmc_project/Common/Callout/README.md +++ b/xyz/openbmc_project/Common/Callout/README.md @@ -1,17 +1,17 @@ ## Introduction A callout is typically an indication of a faulty hardware component in a system. -In openbmc, a callout is defined as any other error, via a YAML file. An example +In OpenBMC, a callout is defined as any other error, via a YAML file. An example would be `xyz.openbmc_project.Error.Callout.IIC`, to indicate an IIC callout. The goal is to have applications post callouts using hardware terminology which is familiar to them, such as a sysfs entry, or an IIC address. It would be up to -the openbmc error handling component to map such a callout to actual field -replacable units (FRUs) on the system. +the OpenBMC error handling component to map such a callout to actual field +replaceable units (FRUs) on the system. ## Architecture and usage -An openbmc error has associated metadata, the same is true for a callout. Such +An OpenBMC error has associated metadata, the same is true for a callout. Such metadata would be defined in the callout YAML interface. Here is an example (for xyz.openbmc_project.Error.Callout.IIC) : ``` @@ -41,7 +41,7 @@ will have to provide values for Foo and IIC metadata. Like mentioned before, due to the presence of the Callout.IIC metadata, the error handling component can figure out that the error Foo includes an IIC callout. -Currently defined callout interfaces in turn inherit +Currently, defined callout interfaces in turn inherit `xyz.openbmc_project.Error.Callout.Device`, which has metadata common to callouts : ``` @@ -77,12 +77,12 @@ in general : the aid of code generated by the system MRW parsers. * Generated code : consider a case where an application wants to callout - an eeprom on the BMC planar, via a device path, such as + an EEPROM on the BMC planar, via a device path, such as /sys/devices/platform/ahb/ahb:apb/1e78a000.i2c/i2c-11/i2c-11/11-0051/eeprom. This would have to be mapped to the BMC planar as the FRU to be called out. MRW parser(s) could be written which, for every device in the IIC subsystem, - can provide a corresponding inventory object path. The error-log server in - this case has to, by looking at the device path, determine that the device + can provide a corresponding inventory object path. The error-log server, in + this case, has to, by looking at the device path, determine that the device is on an IIC bus, and make use of the code generated to map the device to inventory objects. Similar MRW parsers could be written for other device subsystems. |
