#
0ec8b83d |
| 14-Mar-2022 |
Ed Tanous <edtanous@google.com> |
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,
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
show more ...
|