Re: `phosphor-logging` APIs (RFC)

["Andrew Jeffery" <andrew@aj.id.au>]

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