Feedback on Current OpenBMC and Proposing Some Improvements ---- "Improvements" Ideas

[Alex Qiu]

(Splitted from main email thread "Feedback on Current OpenBMC and Proposing
Some Improvements")

"Improvements" Ideas

With the issue examples described above, I came up with some general ideas
on how "Improvements" should look like, which I concluded them into some
high-level design ideas.
Abstraction on entities

I think we need some abstraction to gather the control flow and data into
objects in the code to represent hardware entities. This will greatly
improve debugging, hardware configuration and workaround implementation.
The developers can easily find the code for the hardware or module that
they are dealing with, and it is also clear on the location to implement a
feature for a specific hardware. The control flow can be abstracted into
some interface functions like: onBmcInit(), onHostPowerEvent(),
updateSensorReadings(), readEepromContent(), etc. For most of the hardware,
they can use a common default implementation; for special hardware, they
can override the function to achieve their requirements. For example,
reconfiguring a device register when host 12V power is up; aggregating lots
of temperature sensors to expose only one temperature sensor with maximum
temperature; applying special handling to the emulated EEPROM described
above.
Having a top-down framework of hardware topology

The existing JSON files used in the dynamic software stack can only
represent data, but not any control flow. This led to difficulties where
sometimes some code is preferred to have for aiding the discovery of
hardware topology, condensing redundant configurations, etc. With a good
framework for hardware topology, combining the entity abstraction described
above, developers can easily find the best places to aid the topology
discovery, implement hardware initialization logics, and optimize BMC tasks
according to Linux behaviors.
Better open source and proprietary part management

Construct "Improvements" like a proprietary software supporting plugins.
The philosophy is that the architecture of "Improvements" should be solid
enough that the community won't have to modify the upstream code much. The
community can look at and reference the code upstream to develop their own
code and configs according to their hardware, while the plugin-able part
may be proprietary and can be kept downstream without conflicts.
"Improvements" should have a reasonable plugin API to support common BMC
functionality in the high level, and provide common low-level APIs to
support the plugins by abstracting things like hwmon sysfs interface. This
can be implemented using a plugin system or a flexible build system, as we
are working on an open source project indeed. Whenever we find a potential
conflict between upstream and downstream, let us work it out to see if it
is appropriate to make it pluginable or configurable via config files.
Flexibility for alternatives

Although hwmon sysfs interface is a good starting point for getting sensor
reads from devices, they have their own limitations. The interface does not
abstract every register perfectly, especially when device registers are not
designed to follow some common specs like PMBus, and it does not provide
controls to the devices.

I propose a Device Abstraction Layer to wrap around devices. The underlying
can completely map to hwmon sysfs, or allow user-space driver
implementation if necessary, or even hybrid. This will easily provide an
additional interface to bypass the driver and control the devices, while
still maintaining the benefit to use an off-the-shelf Linux device driver.
Decouple protocol layers more

Quite some existing code is heavily bound to or influenced by the IPMI
protocol layer that we are having right now: We use “uint8_t” type for I2C
bus number in entity-manager for example, while Linux kernel can extend the
logical I2C bus number to more than 512 without any issues. The current
dynamic software stack emphasizes individual sensors, but the BMC handles
many more tasks than just only sensors. The practicality of OpenBMC for
hardware engineers is also hindered by the IPMI as described above in Issue
Examples.

We should have a core designed to consider varieties of tasks that BMC may
be asked to handle: GPIO modifications, I2C manipulations,  The core should
not be hindered by any protocol, but the protocol layer should find its own
way to map the core APIs to its own protocol. This will help us to transit
from IPMI to Redfish.
Backward Compatibility

Although the current dynamic software stack configuration file naming
schema has already taken in some bad label naming like “Name1”, I
understand that the community has also put in a lot of effort to the
current dynamic software stack, and would like to maintain some backward
compatibility somehow to mitigate the transition. I do not have too much
understanding of the compatibility burden that we are dealing with right
now, but just to give a couple of examples: The current JSON configuration
files can be addressed by a common topology discovery module provided as a
basis. For Device Abstraction Layer, we can start with a common module to
still use hwmon sysfs interface for sensors as a basis.

(Back to main thread)

- Alex Qiu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200618/33471836/attachment-0001.htm>