ipmid: switch to lg2

Signed-off-by: George Liu <liuxiwei@ieisystem.com>
Change-Id: I838587b2d564f3c00b78ce37e175d7e8ace51142

clang-format: re-format for clang-18

clang-format-18 isn't compatible with the clang-format-17 output, so we
need to reformat the code with the latest version. The way clang-18
handles lambda forma

clang-format: re-format for clang-18

clang-format-18 isn't compatible with the clang-format-17 output, so we
need to reformat the code with the latest version. The way clang-18
handles lambda formatting also changed, so we have made changes to the
organization default style format to better handle lambda formatting.

See I5e08687e696dd240402a2780158664b7113def0e for updated style.
See Iea0776aaa7edd483fa395e23de25ebf5a6288f71 for clang-18 enablement.

Change-Id: I01547e98d27910919e09ebf7907c86292a6c825d
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

show more ...

unpack: Support std::span as package arguments

Change-Id: Iae594c0d1b10e96dd4fd1a83cdf60c0757f9f3bd
Signed-off-by: Willy Tu <wltu@google.com>

clang-format: copy latest and re-format

clang-format-17 has some backwards incompatible changes that require
additional settings for best compatibility and re-running the formatter.
Copy the latest

clang-format: copy latest and re-format

clang-format-17 has some backwards incompatible changes that require
additional settings for best compatibility and re-running the formatter.
Copy the latest .clang-format from the docs repository and reformat the
repository.

Change-Id: Ic5fd073faa7391d3f0b37787d6a9c7688c9a3253
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

show more ...

Fix std::optional maybe-uninitialized (maybe?)

Attempt to fix the GCC waybe-uninitialized warning for unpackArgs. It
only triggers on compilation of one command handler
(ipmiSensorGetDeviceSdrInfo)

Fix std::optional maybe-uninitialized (maybe?)

Attempt to fix the GCC waybe-uninitialized warning for unpackArgs. It
only triggers on compilation of one command handler
(ipmiSensorGetDeviceSdrInfo) with a single std::optional<uint8_t> param.

The warning is a false positive (I think) but GCC seems to like it if we
get rid of the empty emplace() call in the underlying std::optional
unpack function.

Tested: Compiles in the unit-test docker environment when configured
with `meson setup --reconfigure build -Dwerror=true -Dwarning_level=3
--buildtype=debugoptimized`

Change-Id: Ida8b82dbf2227d3b5339cd4b5756729eeeea9e1d
Signed-off-by: Jonathan Doman <jonathan.doman@intel.com>

show more ...

clang-format: copy latest and re-format

clang-format-16 has some backwards incompatible changes that require
additional settings for best compatibility and re-running the formatter.
Copy the latest

clang-format: copy latest and re-format

clang-format-16 has some backwards incompatible changes that require
additional settings for best compatibility and re-running the formatter.
Copy the latest .clang-format from the docs repository and reformat the
repository.

Change-Id: I44441096113929ce96eb1439e2932e6ff3c87f27
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

show more ...

ipmid: message: fix pack/unpack compile error at aarch64 platform

After debugging with boost/multiprecision owner jzmaddock.
We have found the root cause why boost v1.79.0 got this compile error in

ipmid: message: fix pack/unpack compile error at aarch64 platform

After debugging with boost/multiprecision owner jzmaddock.
We have found the root cause why boost v1.79.0 got this compile error in ipmid.
More detail you can refer from https://github.com/boostorg/multiprecision/issues/472

Root cause:
Boost changed all bit counts from unsigned to std::size_t,
specifically for platforms like arm64 (and windows!) where unsigned is narrower than size_t
so that the maximum representable number isn't unnecessarily constrained.

This then changes the interface for cpp_int_backend to use size_t rather than unsigned for the bit counts.
On most platforms and most use cases, this makes no perceptible difference,
but unfortunately this appears to be one situation where it really does make a difference.

Apparently this is true even though:

template <unsigned N>
using fixed_uint_t =
boost::multiprecision::number<boost::multiprecision::cpp_int_backend<
N, N, boost::multiprecision::unsigned_magnitude,
boost::multiprecision::unchecked, void>>;

Is declared with an unsigned parameter, when partially specializing for fixed_uint_t
you need to use the actual type of the template parameter in the underlying template,
not the type used in the template alias!

Solution:
Change all usage of unsigned for bitcounts to a new typedef bitcount_t
which is size_t for Boost-1.79 and later, and unsigned for Boost-1.78 and earlier.

Verified:
No compile error at aarch64 platform and test ipmitool sdr command is pass.

Signed-off-by: jzmaddock <john@johnmaddock.co.uk>
Signed-off-by: Tim Lee <timlee660101@gmail.com>
Change-Id: Id7a7c86ef854f4b9c06fc4da054c8021f76812b8

show more ...

ipmid: message: pack: Fix cast issue

clang-tidy finds an issue related to below line:

uint64_t bits = t;

where if t is something like unit24_t, it gets compile error:

/usr/local/include/i

ipmid: message: pack: Fix cast issue

clang-tidy finds an issue related to below line:

uint64_t bits = t;

where if t is something like unit24_t, it gets compile error:

/usr/local/include/ipmid/message/pack.hpp:141:18: error: no viable conversion from 'const fixed_uint_t<24U>' (aka 'const number<boost::multiprecision::cpp_int_backend<24U, 24U, boost::multiprecision::unsigned_magnitude, boost::multiprecision::unchecked, void>>') to 'uint64_t' (aka 'unsigned long') [clang-diagnostic-error]

Fix it by using static_cast.

Signed-off-by: Lei YU <yulei.sh@bytedance.com>
Change-Id: I8cda6ec7dc48cab0da38cd1c587eb2da2121d287

show more ...

Add a SecureBuffer class

SecureBuffer is like SecureString, but a specialization of
std::vector<uint8_t> that cleans up after itself

Tested: Executed various ipmi commands to see that they still wo

Add a SecureBuffer class

SecureBuffer is like SecureString, but a specialization of
std::vector<uint8_t> that cleans up after itself

Tested: Executed various ipmi commands to see that they still work

Change-Id: Ifd255ef682d6e46d981de6a5a294d12f3666698b
Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>

show more ...

types: Force underlying int conversion for enums

Boost 1.76.0 changed the behavior of numeric to not accept implicitly
converted ints from enum class types. This breaks many of our casts and
would r

types: Force underlying int conversion for enums

Boost 1.76.0 changed the behavior of numeric to not accept implicitly
converted ints from enum class types. This breaks many of our casts and
would require 2 casts in most cases.

This adds a convenience function to do the underlying type conversions
needed to cast enums to ints and vice versa.

Change-Id: Id653d6a10ef5cab8267c174848940807d693dbf1
Signed-off-by: William A. Kennington III <wak@google.com>

show more ...

fix logic error for unpack vector of tuple

Unpacking a vector of tuples is failing if the correct number of bytes
does not match an integral number of bytes needed to fully unpack all
the tuples.

U

fix logic error for unpack vector of tuple

Unpacking a vector of tuples is failing if the correct number of bytes
does not match an integral number of bytes needed to fully unpack all
the tuples.

Unpacking a tuple should return an error if it does not fully unpack all
the items. This will signal the vector unpack to bail and return however
many items it has unpacked to that point.

A vector unpack should always return success because no matter how many
items it has unpacked, it is fine, because a vector can have any number
of items.

Tested: Unit tests updated to check for proper unpacking of vectors and
tuples (and optionals) as well as new unit tests added for more
targetted testing.

Change-Id: I4b45198f8bc4a49913beb923d10079983179402a
Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>

show more ...

unpack static assert on unsupported types

Unsupported types might not cause compile time errors but can result
in SIGILL errors at runtime when compiler warnings are ignored.

This was found when co

unpack static assert on unsupported types

Unsupported types might not cause compile time errors but can result
in SIGILL errors at runtime when compiler warnings are ignored.

This was found when compiling an intel-ipmi-oem handler that attempted
to unpack an enum class type. The code compiles down to an empty
function (no return statement or value), which can result in all sorts
of undefined behavior. This change forces the unsupported types to emit
a static assert and fail to compile.

Tested: Created a handler that requests an enum class as an input and
saw that the build fails with a static assert.

Change-Id: I123da15cb001756f07761cf7a60b799469926a2a
Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>

show more ...

message/pack: Allow packing payloads

Some IPMI handlers need the ability to support variable return types.
The easiest way to do that is to be able to return payloads and pack
them into the final pa

message/pack: Allow packing payloads

Some IPMI handlers need the ability to support variable return types.
The easiest way to do that is to be able to return payloads and pack
them into the final payload.

Change-Id: I5098a1ab0998ada712096929eae40a3c88a6dea0
Signed-off-by: William A. Kennington III <wak@google.com>

show more ...

message/pack: Support packing string_views

Now we don't need to make an intermediate copy of our data into an array
before packing it into a payload.

Change-Id: Iac79a79e0ae95835cb67d617a966a92ce8d

message/pack: Support packing string_views

Now we don't need to make an intermediate copy of our data into an array
before packing it into a payload.

Change-Id: Iac79a79e0ae95835cb67d617a966a92ce8dcd5f8
Signed-off-by: William A. Kennington III <wak@google.com>

show more ...

message/pack: Check for outstanding bits

Currently, if you pack a non-byte aligned member into a message and then
pack an array, it will do the wrong thing and treat the unaligned data
as being appe

message/pack: Check for outstanding bits

Currently, if you pack a non-byte aligned member into a message and then
pack an array, it will do the wrong thing and treat the unaligned data
as being appended to the end of the message. Allowing for this behavior
is convoluted and probably not useful, so just return an error.

Change-Id: I6f200dbea96c41f49a110ba7536ccfd37115d277
Signed-off-by: William A. Kennington III <wak@google.com>

show more ...

message/payload: Clean up check / trailing state

We want to be able to trivially re-use payloads for marshalling data
from a buffer into other formats. This change tries to make the meaning
of trail

message/payload: Clean up check / trailing state

We want to be able to trivially re-use payloads for marshalling data
from a buffer into other formats. This change tries to make the meaning
of trailingOk and unpackCheck consistent, since the meanings didn't seem
clear in the previous code. Now, unpackCheck is only used to determine
if unpacking was checked, and trailingOk determines if unpackCheck is
required.

This also fixes lots of spurious warnings being printed for commands
which were checking their output correctly, or were legacy and unable to
check output.

Change-Id: Id7aa9266693b4e3f896027acf6b3e5d757fdf981
Signed-off-by: William A. Kennington III <wak@google.com>

show more ...

Fix compilation warning regarding std::variant

When building with SDK, the compiler complains about
’variant’ being not a member of ’std’:

.../pack.hpp:249:24: error: ‘variant’ is not a member of ‘

Fix compilation warning regarding std::variant

When building with SDK, the compiler complains about
’variant’ being not a member of ’std’:

.../pack.hpp:249:24: error: ‘variant’ is not a member of ‘std’

This commit adds appropriate #include to fix that.

Change-Id: I99d6b7c17cbe1f49d706821797cf3fa03ca8c26a
Signed-off-by: Alexander Amelkin <a.amelkin@yadro.com>

show more ...

message/unpack: Fix undefined behavior

It's UB to shift an integer by the size of that integer. More
specifically, if you disable compiler optimization and try and unpack a
32 bit bitset you will en

message/unpack: Fix undefined behavior

It's UB to shift an integer by the size of that integer. More
specifically, if you disable compiler optimization and try and unpack a
32 bit bitset you will end up with a 0x0 mask. Avoid UB by replacing
shift subtract with a negate shift.

Tested:
Unit tests pass now.

Change-Id: I03a6f866a51c955b57787d641da9180841747e4c
Signed-off-by: William A. Kennington III <wak@google.com>

show more ...

Add a tuple type for packing

At the top level, payload had the ability to pack a tuple, but it did it
by splitting it into its parts and packing those individually. But if
one of those parts was a t

Add a tuple type for packing

At the top level, payload had the ability to pack a tuple, but it did it
by splitting it into its parts and packing those individually. But if
one of those parts was a tuple, it would fail. This moves the tuple
packing code into the packing templates so that it is possible to pack a
nested tuple of tuples.

Tested-by: newly written tuple unit tests pass

Change-Id: Icd80926314072df78b0083a823dcfb46e944e365
Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>

show more ...

Add error message to build to make packing type errors clear

Because the base template actually handles things (all integer types),
it needs to ward off non-integer types in a clear way, rather than

Add error message to build to make packing type errors clear

Because the base template actually handles things (all integer types),
it needs to ward off non-integer types in a clear way, rather than
relying on the user seeing that a tuple doesn't have an operator <<(),
for example. This provides a clear message if a specialized pack
operation was not hit.

Tested-by: attempted to build with a non-supported pack type

Change-Id: I66280831e88b4eac903b89f523e5f1a56a53cf9d
Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>

show more ...

Add support for returning optional values

Some commands have optional return values. This allows the handlers to
be defined as returning an optional<T> value and then in the body of the
handler set

Add support for returning optional values

Some commands have optional return values. This allows the handlers to
be defined as returning an optional<T> value and then in the body of the
handler set the value in the optional or not.

Tested-by: unit test runs successfully

Change-Id: Ib38a4589609fb1eb192106e511c9ee3a507ac42f
Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>

show more ...

message: pack: add variant support

Add variant support to allow return of mutliple specific
types. Also change types to const as this is required by
the visitor and these could have been const all a

message: pack: add variant support

Add variant support to allow return of mutliple specific
types. Also change types to const as this is required by
the visitor and these could have been const all along.

Tested: Added unit test and used in oem provider

Change-Id: I5cb056c15d4813b9eee58eecb707664477d019d9
Signed-off-by: James Feist <james.feist@linux.intel.com>

show more ...

ipmid: Compiler-generated unpacking and packing of messages

handler.hpp has the templated wrapping bits for ipmi command handler
callbacks implemented.

message.hpp has the serialization/deserializa

ipmid: Compiler-generated unpacking and packing of messages

handler.hpp has the templated wrapping bits for ipmi command handler
callbacks implemented.

message.hpp has the serialization/deserialization of the ipmi data
stream into packed tuples for functions.
message/pack.hpp and message/unpack.hpp contain the actual serialization
and deserialization of types.

Change-Id: If997f8768c8488ab6ac022526a5ef9a1bce57fcb
Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>

show more ...