Merge dbus interface and error log meta data definition

[geissonator]

No description provided.

[geissonator]

Task List

• Send email to distro, get approval of design plan
• Define yaml format in dbus repo for error codes, upload code showing example - https://gerrit.openbmc-project.xyz/#/c/1007/
• Get existing parsing script to work with new yaml format - https://gerrit.openbmc-project.xyz/#/c/1104/
• Generate source file required by server side to determine meta data (error code to meta data string mapping) - https://gerrit.openbmc-project.xyz/#/c/1130/
• Update recipes to handle dependency between dbus yaml and logging yaml (ensure we build dbus first and export it's yaml for logging repo to use) - https://gerrit.openbmc-project.xyz/#/c/1007/, https://gerrit.openbmc-project.xyz/#/c/1193/, https://gerrit.openbmc-project.xyz/#/c/1191/, https://gerrit.openbmc-project.xyz/#/c/1192/

Questions: The dbusplus code will probably require the generated hpp file from the log component (error validation and exception handling), can our build env handle this dual dependency issue?

Some notes from talking with Patrick:

• Each object will create a error yaml file (ex. tools/example/net/poettering/Calculator.errors.yaml)
• There will be a common yaml, Common.errors.yaml from which all methods can use
• Objects can use other objects errors if they like, but we should ensure it shouldn't be in common
• dbusplus will have a set of errors that users will also need to watch for (invalid operation, unknown property, ...)

[geissonator]

The final part of this requires some more work within the phosphor-dbus-interfaces repo (i.e. the initial makefile and recipes need to be created). Then the work from this story can be run as a part of that build process. Going to reduce this to 2 pts for the work to the scripts and create a seperate 1 pointer to incorporate them into the phopshor-dbus-interface repo once that work is done.