meson: Migrate to boolean HAVE_LIBPLDM_API_* macros

This frees up the LIBPLDM_API_* macros for applying attributes to
structs, struct members, and functions.

Change-Id: I7c12b634ee78c2246fa0070a213

meson: Migrate to boolean HAVE_LIBPLDM_API_* macros

This frees up the LIBPLDM_API_* macros for applying attributes to
structs, struct members, and functions.

Change-Id: I7c12b634ee78c2246fa0070a213459b5b6da46fe
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>

show more ...

OWNERS: Tidy up throughout the tree

Two things are only really needed to be stored once:

- The blurb about how the OWNERS file is structured
- List items under the 'openbmc' key

Rework the subtree

OWNERS: Tidy up throughout the tree

Two things are only really needed to be stored once:

- The blurb about how the OWNERS file is structured
- List items under the 'openbmc' key

Rework the subtree OWNERS files to eliminate the redundancies

Change-Id: I385e0c1e57fd1ab59bb3367d9751ff05a38e6aab
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>

show more ...

bindings: C++ binding for parsing PLDM fw package

This binding enables convenient parsing of the PLDM fw update package in
C++ code. The entire package header is parsed and can be queried.

It has s

bindings: C++ binding for parsing PLDM fw package

This binding enables convenient parsing of the PLDM fw update package in
C++ code. The entire package header is parsed and can be queried.

It has since been modified to remove exceptions and rely less on mutable
instance variables.

The ABI compatibility of the C++ bindings is controlled in the same way
as the C code, with the LIBPLDM_ABI_* annotations on all public
functions.

The ABI stability is provided by using growable structs. See [2] for an
explanation.

When DMTF adds new data members to the firmware update package, these
can simply be appended to the end of the growable struct.

How can applications safely handle those structs?

Consider Application A1, compiled against libpldm++ version N-1
and linked against libpldm++ version N.

Assume libpldm++ version N has a new field as part of a given struct.

A1 will then receive a structure larger than what it expects and only
access a subset of the fields within.

Consider Application A1, compiled against libpldm++ version N and
linked against libpldm++ version N-1.

A1 will receive a structure smaller than what it expects. A1 must always
check for existence of any struct member which was introduced later than
DSP0267 version 1.0.0 [3].

Applications should never by themselves create instances of the structs
provided by this API since the version of libpldm++ they are linked
against may be lower and may not have a constructor for the version of
that struct the application is compiled against.

References:
[1] https://github.com/openbmc/pldm/blob/a1871174860e8927d19a0d57ac4cf9d55b0514ca/fw-update/package_parser.cpp
[2] https://github.com/lotem/mighty_struct/blob/master/mighty_struct_explained.md
[3] https://www.dmtf.org/dsp/DSP0267

Change-Id: Ib6cbff302be0e52d30125bcf08687ba42f7fc93f
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>

show more ...