Feature: Cargo feature - minitrace/max_level_off and minitrace/release_max_level_off

[taqtiqa-mark]

In general I don't, yet, believe there is use for Minitrace counterparts to the Logging and Tracing crates features related to levels debug, warn, error and info.

I believe users are better served by leaving levels to the application author to setup via cfg/cfg_attr and Cargo features - supported by some documentation/guidance/template.

That said, I do think there is utility in Minitrace having the features (named for consistency with Logging and Tracing crates):

• max_level_off
• release_max_level_off

These features would control the value of some constant. The proc-macro-attribute #[trace(...)]checks this constant value before constructing a span. By default, span creation is enabled.

[andylokandy]

cc @zhongzc

[zhongzc]

I agree that we provide the same max_level_* and release_max_level_* like log.

Ref: https://docs.rs/log/latest/log/#compile-time-filters

[taqtiqa-mark]

I agree that we provide the same max_level_* and release_max_level_* like log.

Hmm, I'm actually against implementing max_level_* and release_max_level_* like log, and I am only proposing/suggesting support for max_level_off and release_max_level_off.

I'm not sure that anyone is proposing we limit the levels the Minitrace supports. That is, currently Minitrace does not constrain users to adopt any particular level hierarchy. I'd like to keep things that way, at least that is my current thinking.

My concern is that having:

... max_level_* and release_max_level_* like log

is a usability restriction/limitation with no performance/run-time benefit.

[andylokandy]

Discussed in https://github.com/tikv/minitrace-rust/issues/96