Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Experiment with using tracing instead of log #1014

Open
kevinaboos opened this issue Jul 22, 2023 · 6 comments
Open

Experiment with using tracing instead of log #1014

kevinaboos opened this issue Jul 22, 2023 · 6 comments

Comments

@kevinaboos
Copy link
Member

kevinaboos commented Jul 22, 2023

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.

@noryve-03
Copy link

Hello. Been playing around with tracing on my local directory. Is there anyone working on this issue @kevinaboos ?

@kevinaboos
Copy link
Member Author

Nope, as far as I know it's just an idea. Feel free to go for it!

@noryve-03
Copy link

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.

@kevinaboos
Copy link
Member Author

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.

@noryve-03
Copy link

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.

@kevinaboos
Copy link
Member Author

oh true, you may need to do that. I'm not sure, part of the fun is finding out! 😃

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants