All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Williams <patrick@stwcx.xyz>
To: William Kennington <wak@google.com>
Cc: 郁雷 <yulei.sh@bytedance.com>, openbmc <openbmc@lists.ozlabs.org>,
	"Brad Bishop" <bradleyb@fuzziesquirrel.com>
Subject: Re: OpenBMC Logging and Error Handling Dos and Don'ts
Date: Tue, 2 Jun 2020 18:06:39 -0500	[thread overview]
Message-ID: <20200602230639.GK17541@heinlein> (raw)
In-Reply-To: <CAPnigKku77Tc60TAAb_yTJaWNePYWM204BF8erJS7CjhxrAPRA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2627 bytes --]

On Mon, Jun 01, 2020 at 11:07:46PM -0700, William Kennington wrote:
> If you use the fmt library it would only require one extra temporary string
> to be constructed and it works trivially with something like phosphor
> logging.
> 
> log<level::INFO>(fmt::format("My error: {}", filename));
> 
> It also has the advantage of understanding basic c++ types like
> std::strings and std::string_views.
> 
> On Mon, Jun 1, 2020 at 8:33 PM 郁雷 <yulei.sh@bytedance.com> wrote:
> 
> > I have a bit concern about this. The existing phosphor-logging API
> > does not support this well.
> > Specifically, it does not support the "printf" way to generate a
> > string with the variables to log.
> > So previously we typically put the variables in entries.
> > I do agree that logging the variables in the MESSAGE field is much better.
> > But to encourage such logging, the logging API should be enhanced to
> > support the "printf" way.
> > E.g.
> >     log<level::INFO>("Something is wrong: %s:%d", xx, xxx);
> > is much better than:
> >     std::string to_log = xxx; // generate the message manually
> >     log<level::INFO>(to_log);
> >
> > Otherwise, it's really not convenient to write such logging code.
> >

Separate from this proposal from Brad, I'd like to work on a
next-generation of phosphor-logging.  When we originally implemented
phosphor-logging we were all pretty new to C++14.  I think there can be
some great improvement in the syntax of phosphor-logging now that we
have C++17 (and more experience).

The biggest change I'd like to do is in the way the structured entries
are defined, but I think we can improve the verbosity of syntax in
making a log in general.

Some example syntax:

// Current syntax (and I'm being especially verbose on the namespaces).
phosphor::logging::log<phosphor::logging::level::ERR>("Some message",
    phosphor::logging::entry("EXAMPLE=%s"), example_str);

// Potential syntax
lg::error("Some message", "EXAMPLE"_s, example_str);

In a code-review I was on, we had some discussions about how difficult
it is to create data that isn't in the "-o verbose" and I think William
and Lei are both referring to that as well.  I am concerned that a
generic format leads us more to unstructured logging, which personally I
don't like.  My suggestion is that we have some easy syntax to indicate
"also put this structured data into the raw message" so that my example
above the message becomes "Some message. EXAMPLE='the string'".

I'd be interested to hear what "next generation logging" others have in
mind.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2020-06-02 23:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-01 20:35 OpenBMC Logging and Error Handling Dos and Don'ts Brad Bishop
2020-06-02  3:32 ` 郁雷
2020-06-02  6:07   ` William Kennington
2020-06-02 23:06     ` Patrick Williams [this message]
2020-06-02 23:09       ` William Kennington
2020-06-03  0:07       ` Vernon Mauery
2020-06-03  2:51         ` 郁雷
2020-06-03 19:02         ` Vijay Khemka
2020-06-03 19:17           ` Johnathan Mantey
2020-06-03 19:25             ` William Kennington

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200602230639.GK17541@heinlein \
    --to=patrick@stwcx.xyz \
    --cc=bradleyb@fuzziesquirrel.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=wak@google.com \
    --cc=yulei.sh@bytedance.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.