OpenBMC Logging and Error Handling Dos and Don'ts

[William Kennington]

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 at bytedance.com> wrote:

> > ---
> > ## Don't require `-o verbose` for systemd journal MESSAGE field context
> > The MESSAGE field of a systemd journal entry should be self describing
> and not
> > rely on additional structured log data.  For example when the MESSAGE
> field
> > references a filesystem path, the path should appear in the MESSAGE
> field.
> > When the MESSAGE field references a failed system call, the system call
> and the
> > return value should appear in the MESSAGE field.  This keeps the journal
> > informative and useful for casual journal users.  Note that it is
> perfectly
> > acceptible to add (duplicate) structured log entry values for the data
> that
> > appears in MESSAGE.  This guideline only prescribes that the data _not_
> be
> > omitted from the MESSAGE field value.
> >
>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200601/c6fefae9/attachment.htm>