theseus-os
Experiment with using `tracing` instead of `log`
Proposed Benefits
The log crate is decent and easy to support, but it lacks some of the nicer features of more powerful logging systems like tracing. For example, it'd be nice to have an easier way to disable all log statements in a certain crate or module, or of a certain level within a given file, etc. The structured logging and span functionality all look attractive too.
Most importantly, this would help a user/developer more easily filter out the log statements that are of interest to them in a specific testing/debugging scenario. With log macros, we just have to generally enable all logging levels in all crates, and then tediously grep for keywords or file names.
Considerations
The tracing crate does support no_std, but interestingly enough it requires alloc support on no_std. So that means we can use it in most crates, but not all crates (i.e., those that must run during early bootstrap before heap allocation is initialized).
First steps
If anyone is interested in helping out, the best/easiest first step would likely be to play around with tracing as a drop-in replacement for log, which is easy enough because it offers the same basic macros.
Hello. Been playing around with tracing on my local directory. Is there anyone working on this issue @kevinaboos ?
This issue is intimidating as the scale is huge. Any ideas on incremental improvements? I was thinking of first making a PR for the kernel, then another for applications.
Definitely! I understand the scale is intimidating. I think a good first step is to look at only the kernel/logger crate, which acts as a logger backend and implements the required traits from log.
The tracing crate can supposedly work as a drop-in replacement for log, so you should only need to look at our one logger crate to make the relevant changes.
Note that there is no difference in how an application vs a kernel crate does logging in Theseus, they currently all go to the same log stream.
Thank you for the answer! But if I change the backend, won't it also be necessary to replace each call to the log crate with a call to the tracing crate? Maybe I should not be worried about that? Let me first finish my changes on the kernel/logger crate, then I will worry about that.
oh true, you may need to do that. I'm not sure, part of the fun is finding out! :smiley:
AFAIK, tracing is a drop-in replacement for log (based on what i've heard), but you may be correct in that it doesn't directly work with crates that use macros from the actual log crate itself.