tree 207fa734b40162e4953f4c8c229cbcfb4c02900d
parent 7e8890c5c2b8d69c104f2db4e82fb06c40374c08
author Ed Tanous <edtanous@google.com> 1647295007 -0700
committer Ed Tanous <edtanous@google.com> 1670530081 -0800

Generate Redfish enums from schemas

OpenBMC tends to have a significant problem in doing the appropriate
lookups from the schema files, and many bugs have been injected by users
picking a bad enum, or mistyping the casing of an enum value.

At the same time, nlohmann::json has recently added first class support
for enums, https://json.nlohmann.me/features/enum_conversion/

This commit attempts to build a set of redfish includes file with all
the available Redfish enums in an easy to use enum class.  This makes it
very clear which enums are supported by the schemas we produce, and adds
very little to no extra boilerplate on the human-written code we
produced previously.

Note, in the generated enum class, because of our use of the clang-tidy
check for macros, the clang-tidy check needs an exception for these
macros that don't technically follow the coding standard.  This seems
like a reasonable compromise, and in this case, given that nlohmann
doesn't support a non-macro version of this.

One question that arises is what this does to the binary size....  Under
the current compiler optimizations, and with the current best practices,
it leads to an overall increase in binary size of ~1200 bytes for the
enum machinery, then approximately 200 bytes for every call site we
switch over.  We should decide if this nominal increase is reasonable.

Tested: Redfish protocol validator runs with same number of failures as
previously.
Redfish Service Validator passes (one unrelated qemu-specific exception)

Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I7c7ee4db0823f7c57ecaa59620b280b53a46e2c1