Re-think logging in smithay

[Drakulix]

Logging in smithay is currently implemented using slog.
While it has been a decent choice at the time, it has grown to be a little cumbersome in some regards.

(This is mostly an aggregation of arguments raised regarding this issue in a recent discussion over at our Matrix channel.)

• slog requires a Logger to be passed around and stored.
  • While this is not necessarily true, slog discourages the use of slog_scope in libraries for good reason
  • While the smithay api does allow the user to pass in None instead of an logger, that is still translated into an actual logger instance, that needs to be passed around in smithays internals.
• slog is part of our public api, which may be an issue, if slogs very conservative versioning sees some actual api breakage.
  • If we decide to change our logging library, we should fix this anyway to make the api independent of the logging internals in the future.

However slog also has a set of desirable advantages:

• Easy compatibility with the broad log ecosystem. Whatever might takes it's place, should support that as well
• User-provided logging contexts. This is different from logging scopes, which can't be different on different calls to the same method. The context held by slog's loggers is stored and attached to every log message. The logger is local to the struct we call a method on, which is why it is static. This kind of property will be referred to as contexts in the following discussion.

slog noticeably lacks in the following regards:

• It provides no logging scopes, that could be utilized by libraries. Meaning that logging contexts are static for upcoming method calls and cannot be dynamically adjusted.

Notice at this point, that contexts can be simulated via scopes, by using the same scope for every call to the same struct, while contexts fail to emulate the latter due to their static nature.

This sounds like a clear argument for scopes as they can emulated all of slogs functionality, without explicitly passing a logger. But the static nature of contexts has it's own advantages. Often the scopes context is actually static and the user might prefer to pass in the context once on struct creation, instead of setting a matching scope for every method call (which in turn the user would have to store themselves or construct on every call, we would mostly delegate the problem for static contexts).

So a strong contender for a slog successor would allow:

• Using contexts, where appropriate and skip them (to get rid of contexts in the public api / None arguments) in other parts of smithay
• Using scopes as they are the more powerful tool, that can even be used where the use of contexts was not intended.
• Can be easily hidden from the public api, without dublicating a lot of code
• Integrates well with log.

Notice that emulating contexts with scopes can be very easy, if a scope-based logging library would allow snapshoting and storing the current scope on object creation.
This solution even gets rid of any Context argument in the public api, but introduces a bit of implicit api (which can be viewed as an issue, but is arguably negligible given smithay's usually very strongly typed api).

Also note that any scope-api that is based on an existing library, will cause side-effects for users of smithay, that use said library on their own. Effectively any library like this will be part of an implicit public api. If this may lead to undesired side-effects and should possibly be avoided, but that has not yet been debated.

Possible candidates are (not exhaustive):

• log itself. log has an ongoing issue on structural logging support. With that in place context/scope apis could be easily hand-writting and deployed on top of log.
• tracing is a very new library from the tokio-universe.
  • While born from the requirements of a proper logging solution for async-rust programs, this is a standalone logging library with a strong focus on Spans. Spans are essentially, what is described in our scope-concept.
  • Spans can be stored, which means emulating a context can be done implicitly as outlined above.
  • tracing has some compatibility with log, but that seems to be mostly focused on passing log-messages into tracing and not the other way around. (to be investigated)
  • There is the argument to make, that control-flow in tokio-based apps is quite different from what we usually have in smithay. Given tracings origin, the api needs to be examined careful, which has not been done yet.
  • tracing has a vast ecosystem already with error backtraces, flamegraphs and more just to name a few.
  • scopes introduce side-effects for user, that use tracings Spans on their own.
• slog_scope. We could throw caution to the wind and just ignore slog's recommendation and use slog_scope to get rid of the Logger arguments.
  • We could expose a public scope-api wrapping slog and copy the current logger to store contexts
  • We remain compatible with log
  • We introduce side-effects for user, that use slog-scope on their own.
  • The changes to our code-base would likely be very minimal.

[i509VCB]

I imagine the cost of maintaining a logging abstraction in smithay is a prospect which some people may not like since it adds more code to have to maintain. In my opinion one of the other crates would do a better job and remove this issue of needing more abstraction.

Assuming the log crate's structural extensions get stabilized, that crate being under the rust-lang organization will make it probably the most widely used crate of it's kind, and therefore it would make sense to use in smithay since the crate is widely supported throughout the ecosystem.

Although I feel we will probably suffer as similar issue to having slog in public api with one of the other crates as well, just don't know to what extent those crates are religious about bumping versions and not allowing breaking changes.

[DemiMarie]

To reduce dependencies and allow producing smaller binaries, it would be useful to be able to build with no logging support whatsoever.

[heavyrain266]

I feel like tracing is the way to go, smithay and sctk can provide custom layers which allow users to costumize logs on their own and then inject SmithayLayer on top to see logs from compositors and clients. Tracing is also compatible with log crate but it's "unstable" feature yet.

Example layer implementation from tracy_full, tracy profiler integration.

Example implementation form user's point of view:

use smithay::logs::SmithayLayer;

tracing::subscriber::set_global_default(
    tracing_subsriber::registry::with(SmithayLayer);
);

[bwidawsk]

This can be closed now :-)