| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
If we are caught in an exception unwind we don't care that the
payload is not be fully checked. Otherwise, this encourages the pattern
of wrapping all handler code in try catch blocks that set trailingOk as
it is not required to read the entire payload when throwing an
exception.
Change-Id: I35149eedd33bd9fd41968e89d5a8614df7436872
Signed-off-by: William A. Kennington III <wak@google.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
| |
Platform Event Message Command requires that if the message
comes in over IPMB, the generator ID is the rqSA of the message.
IPMB bridge is now responsible for passing this in via the options
map so it can be passed in the context to the command.
Change-Id: I52b7c9ef23896a4efcceeebf12559bbdf897d1c2
Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
After some feedback from users of the new IPMI API, they wanted to see
two things:
1) don't require ipmid/api.hpp and ipmid/registration.hpp to be able to
write new handlers
2) only require including ipmid/api.hpp (instead of ipmid/api.h)
So now, by simply including ipmid/api.hpp instead of ipmid/api.h
(deprecated), handlers incorporating the new IPMI API can be written.
Change-Id: I446dcce70cff03d4ecc28c658292d052485f77fc
Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>
|
|
|
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>
|
