Describe callout creation

Add a section in README.md to describe how callouts are created from the
callout metadata fetched from the journal.

Change-Id: I27d89f66aa9318b855f6879ccb91efb8ba9e5fa8
Signed-off-by: Deepak Kodihalli <dkodihal@in.ibm.com>

1 files changed, 29 insertions, 0 deletions

diff --git a/xyz/openbmc_project/Error/Callout/README.md b/xyz/openbmc_project/Error/Callout/README.md
index 14a5397..0636e81 100644
--- a/xyz/openbmc_project/Error/Callout/README.md
+++ b/xyz/openbmc_project/Error/Callout/README.md
@@ -57,3 +57,32 @@ device path, for lack of IIC information. The application can add the callout
 metadata fields for both Callout.Device and Callout.IIC, but provide values
 only for Callout.Callout. That way the error handling component can still
 decipher this as an IIC callout.
+
+## Creation of a callout
+
+This section talks about creation of a callout, once callout related metadata is
+already in the journal.
+
+Taking an example of a generic device callout here, but this would be the flow
+in general :
+
+* An application commits an error that has associated callout metadata. This
+  will cause the error-log server to create a d-bus object for the error.
+
+* The error-log server will detect that callout metadata is present, will
+  extract the same and hand it over to a sub-module which will map callout
+  metadata to one or more inventory object paths, and will create an
+  association between the error object and the inventory object(s). The
+  mapping from callout metadata to inventory objects is mostly done via
+  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
+  /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
+  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.