`phosphor-logging` APIs (RFC)

Andrew Jeffery andrew at aj.id.au
Thu Jul 29 09:34:14 AEST 2021

On Wed, 28 Jul 2021, at 15:55, Patrick Williams wrote:
> On Wed, Jul 28, 2021 at 03:22:43PM +0930, Andrew Jeffery wrote:
> > On Wed, 28 Jul 2021, at 05:54, Patrick Williams wrote:
> > >     - 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).
> Can you give me a concrete example of what you mean by this?  I'm not
> understanding.

I've left a comment on the patch:


But duplicating that here, how I'd like to use the API and what I'd 
like to see in the resulting journal message is:

value = "xyz.openbmc_project.EntityManager";
lg2::error("Error talking to {ENTITY} error code is {ERRNO}", "ENTITY", value, "ERRNO", 2);

The lg2 implementation renders the values into the format string and 
forwards the result as MESSAGE to the journal, along with the 
structured values (ENTITY and ERRNO in the example).

$ journalctl -b
Nov 25 13:13:09 bmc fansensor[3006]: Error talking to xyz.openbmc_project.EntityManager error code is 2

Better yet would be if we could just forward the format string and 
journalctl renders this at invocation time, but we'd need to work with 
upstream on that.


More information about the openbmc mailing list