Conversation
Jarkko Sakkinen
jarkko
Edited 13 days ago
There's coding conventions, commit message conventions (kernel has one, there's conventional commits etc.) but is there log message recommendations?
I'm mainly thinking in context of system daemons (not web services or internet exposing stuff).
You can e.g., say that something "failed" or alternatively you are "unable" to perform that task etc. I've worked on this small daemon for two weeks and this is the stuff where I don't know what I'm doing.
Actually, I often have hard times reviewing log messages even as a kernel maintainer. I don't really have any guidelines for klog messages that would stick on me. Maybe there should be a document for this like we have for coding conventions and patch submissions. I dunno.
I'm mainly thinking in context of system daemons (not web services or internet exposing stuff).
You can e.g., say that something "failed" or alternatively you are "unable" to perform that task etc. I've worked on this small daemon for two weeks and this is the stuff where I don't know what I'm doing.
Actually, I often have hard times reviewing log messages even as a kernel maintainer. I don't really have any guidelines for klog messages that would stick on me. Maybe there should be a document for this like we have for coding conventions and patch submissions. I dunno.
1
1
2
Even in kernel log messages are total chaos. It would be also bad if they were forced to be some weird tokenized structure (aka machine readable) and they loose their purpose, and you can store that type of history data elsewhere tuned for the application.
The middle-ground would be to define recommendations choice of words, vocabulary and grammar to apply in broadly defined scenarios. This would especially help in projects such as kernel where non-native speaker might have difficulties to figure out the "right language" by instinct.
Thus, it would relax the project ecosystem more than it would make it more constrained, as you don't have to spend too much energy in such a low priority topic, and focus on important matters.
The middle-ground would be to define recommendations choice of words, vocabulary and grammar to apply in broadly defined scenarios. This would especially help in projects such as kernel where non-native speaker might have difficulties to figure out the "right language" by instinct.
Thus, it would relax the project ecosystem more than it would make it more constrained, as you don't have to spend too much energy in such a low priority topic, and focus on important matters.
1
0
0
@jarkko Groups (i.e. big companies) have tried to come up with a standard way for all kernel log messages, as that is what they were used to for their "other" operating systems. They wanted a big book, they could reference, to look up what each message meant and what to do about it if it showed up.
After many "discussions" with the community, I think in the end they got something they could use on the back-end to tokenize the kernel messages from the source, and somehow create unique identifiers they can use in other tools, but I don't remember the specifics. Odds are it's buried in the kbuild system somewhere....
After many "discussions" with the community, I think in the end they got something they could use on the back-end to tokenize the kernel messages from the source, and somehow create unique identifiers they can use in other tools, but I don't remember the specifics. Odds are it's buried in the kbuild system somewhere....
1
0
1
@gregkh I think softer recommendations/practices would go a long way. I would not want to use machine readable tokenized system for log messages. For that something like eBPF is probably a better idea :-) And using klog "as instrumentation protocol" (or that kind of picture I got from your description) is scary idea from security standing point.
1
0
0