`phosphor-logging` APIs (RFC)
Andrew Jeffery
andrew at aj.id.au
Wed Jul 28 15:52:43 AEST 2021
On Wed, 28 Jul 2021, at 05:54, Patrick Williams wrote:
> Greetings,
>
> There have been discussions before on this mailing list about the APIs present
> in phosphor-logging and some of the shortcomings they have. I've implemented a
> new API, inside phosphor-logging, that I think resolves the issues discussed
> here and in some offline forums.
>
> If you have an interest in the logging APIs, I would appreciate any feedback you
> may have. If there are additional issues with the APIs that I might have
> missed, please feel free to let me know and I'll see what can be done about
> resolving them.
>
> lg2: introduce motivation and API
> https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-logging/+/45310
> lg2: initial implementation of C++20 structured logging
> https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-logging/+/45311
>
> The main highlights of what I attempted to fix are:
> - Verbose and clumsy API for previous `logging::log`.
> - Poor compile-time identification of certain (common) issues.
> - Source location data is invalid (issue openbmc/openbmc#2207).
I think you wanted openbmc/openbmc#2297 there, but yes!
> - Useful data is missing from `journalctl` resulting in people working
> around it by generating strings with `fmt` et.al.
Sounds promising! Reading the proposal it seems like you're appending
certain bits of structured data to the message. I think it would be
nice if the data could be interpolated into arbitrary positions and not
just appended (note, I'm not asking for interpolation of arbitrary
variables here unlike what can be achieved with raw use of fmt, only
those captured via the structured logging).
> - No logging present when running on a TTY.
Great, this has caused quite a bit of confusion in the past.
Andrew
More information about the openbmc
mailing list