tool: init configurable logging #121
No reviewers
Labels
No labels
bug
dependency
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
review-next
security
stub
tool
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: raito/lanzaboote#121
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "tool-configurable-logging"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Replace
println()
calls with logging at different levels using thelog
crate.Closes #55 #73
Typically logging goes to stderr to avoid buffering log messages. But at that point, you just re-implement stderrlog. Why not use that? It also gives you the typical Unix behavior of
-v
,-vv
,-vvv
.This sounds like
error!
or at leastwarn!
? I mean if this is not an error what is? :) In case of errors, it also makes sense to dump all information required for debugging that you have at hand immediately.But maybe the log message should be at the call site of
verify
, otherwise legitimate uses of verify might spam the log?I would strongly suggest to just use
stderrlog
. It brings minimal dependencies and has functionality that is actually useful.(Optional)I would also encourage you to write a small piece of documentation somewhere about the logging policy. Maybe we start a developer guideline?
My personal view is (up for debate):
Right now this function is called only to check if the systemd-boot binary is signed or not. There, it should not be
error
because we just update the binary if it not signed (e.g. because you just installed Lanzaboote). So you're right it should be at the call site. Maybe a warning makes more sense than an info. But there is really nothing for the user to do, that's why it maybe should be an info?Never heard of the stderrlog crate before but it looks good. I'm not too fond of the multiple -vvv flags, since I do not believe that a normal CLI user would be interested in anything besides normal output and debug output. However, since Lanzaboote is not really a normal CLI, as it is only called by a module, we might as well implement all log levels.
Thanks for the review @blitz! I think we can/should address the logging policy separately. I opened an issue for a contributors guide #124. We should follow the
Level
s from the log crate IMOI don't love this. Do you have any idea how to make this more concise?
I think it's good enough. I personally would move it into the
if
statement that does the actual installation, but it doesn't really matter.Looks good!
LGTM! Thanks!