OpenBMC Logging and Error Handling Dos and Don'ts

[郁雷]

> ---
> ## 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.