meson: Add packageconfig for libpldm++

libpldm++ needs a packageconfig (.pc) file for yocto recipes to find
it as a dependency.

Add one here similar to how it's done for libpldm.

Also adjust the p

meson: Add packageconfig for libpldm++

libpldm++ needs a packageconfig (.pc) file for yocto recipes to find
it as a dependency.

Add one here similar to how it's done for libpldm.

Also adjust the packageconfig description for libpldm to reflect the
current scope of the library.

Tested: yocto image build succeeds when libpldm++ is configured as a
dependency for phosphor-software-manager.

Fixes: d6a957481638 ("bindings: C++ binding for parsing PLDM fw package")
Change-Id: I3c3ebbdb57d68b81c0fbd55ff110768f50a94446
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>

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 ...