Repository files navigation

Entity manager is a design for managing physical system components, and mappingthem to software resources within the BMC. Said resources are designed to allowthe flexible adjustment of the system at runtime, as well as the reduction inthe number of independent system configurations one needs to create.

A server component that is physically separate, detectable through some means,and can be added or removed from a given OpenBMC system. Said component can, andlikely does contain multiple sub-components, but the component itself as a wholeis referred to as an entity.

Note, this term is needed because most other terms that could've been used(Component, Field Replaceable Unit, or Assembly) are already overloaded in theindustry, and have a distinct definition already, which is a subset of what anentity encompasses.

A particular feature of an Entity. An Entity generally will have multipleExposes records for the various features that component supports. Some examplesof features include, LM75 sensors, PID control parameters, or CPU information.

A set of rules for detecting a given entity. Said rules generally take the formof a D-Bus interface definition.

Entity manager has the following goals (unless you can think of better ones):

1. Minimize the time and debugging required to "port" OpenBMC to new systems
2. Reduce the amount of code that is different between platforms
3. Create system level maintainability in the long term, across hundreds ofplatforms and components, such that components interoperate as much asphysically possible.

A full BMC setup using Entity Manager consists of a few parts:

1. A detection daemon This is something that can be used to detectcomponents at runtime. The most common of these, fru-device, is included inthe Entity-Manager repo, and scans all available I2C buses for IPMI FRUEEPROM devices. Other examples of detection daemons include:peci-pcie: A daemon that utilizesthe CPU bus to read in a list of PCIe devices from the processor.smbios-mdr: A daemon thatutilizes the x86 SMBIOS table specification to detect the available systemsdependencies from BIOS.

   In many cases, the existing detection daemons are sufficient for a singlesystem, but in cases where there is a superseding inventory control system inplace (such as in a large datacenter) they can be replaced with applicationspecific daemons that speak the protocol information of their controller, andexpose the inventory information, such that failing devices can be detectedmore readily, and system configurations can be "verified" rather thandetected.

2. An entity manager configuration file Entity manager configuration filesare located in the ./configurations directory in the entity managerrepository, and include one file per device supported. Entities are detectedbased on the "Probe" key in the json file. The intention is that this foldercontains all hardware configurations that OpenBMC supports, to allows an easyanswer to "Is X device supported". An EM configuration contains a number ofExposes records that specify the specific features that this Entity supports.Once a component is detected, entity manager will publish these Exposesrecords to D-Bus.

3. A reactor The reactors are things that take the entity managerconfigurations, and use them to execute and enable the features that theydescribe. One example of this is dbus-sensors, which contains a suite ofapplications that input the Exposes records for sensor devices, then connectto the filesystem to create the sensors and scan loops to scan sensors forthose devices. Other examples of reactors could include: CPU managementdaemons and Hot swap backplane management daemons, or drive daemons.

note: In some cases, a given daemon could be both a detection daemon and areactor when architectures are multi-tiered. An example of this might include ahot swap backplane daemon, which both reacts to the hot swap being detected, andalso creates detection records of what drives are present.

Entity Manager will automatically create associations between its entities incertain cases. For details see theassociations doc.

1. Entity manager shall support the dynamic discovery of hardware at runtime,using inventory interfaces. The types of devices include, but are not limitedto hard drives, hot swap backplanes, baseboards, power supplies, CPUs, andPCIe Add-in-cards.

2. Entity manager shall support the ability to add or remove support forparticular devices in a given binary image. By default, entity manager willsupport all available and known working devices for all platforms.

3. Entity manager shall provide data to D-Bus about a particular device suchthat other daemons can create instances of the features being exposed.

4. Entity manager shall support multiple detection runs, and shall do theminimal number of changes necessary when new components are detected or nolonger detected. Some examples of re-detection events might include hostpower on, drive plug/unplug, PSU plug/unplug.

5. Entity manager shall have exactly one configuration file per supported devicemodel. In some cases this will cause duplicated information between files,but the ability to list and see all supported device models in a singleplace, as well as maintenance when devices do differ in the future isdetermined to be more important than duplication of configuration files.

1. Entity manager shall not directly participate in the detection of devices,and instead will rely on other D-Bus applications to publish interfaces thatcan be detected.
2. Entity manager shall not directly participate in management of any specificdevice. This is requirement is intended to intentionally limit the size andfeature set of entity manager, to ensure it remains small, and effective toall users.

bmcweb A webserver implementation that uses the inventory information fromentity-manager to produce a Redfish compliant REST API.intel-ipmi-oem Animplementation of the IPMI SDR, FRU, and Storage commands that utilize EntityManager as the source of information.

1. Entity Manager DBus API
2. My First Sensor Example
3. Configuration File Schema
4. EEPROM address size detection modes