You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The use of msg_err, msg_debug, msg_warn, etc. is just a way to deliver crude system messages directly to the console. We could use a logging facility that allows vectoring of messages between the console, a persistent log file, or a socket. It might not be a bad idea to figure out how these log entries might exist in a tuplified version, where things like time, debug level, subsystem, etc., are stored as attributes.
This will require some thinking through and discussion before coding.
The text was updated successfully, but these errors were encountered:
With #2079, the msg_*() macros print console messages based on their log level and the kernel's configured logging level (err, warn, info). Supported consoles in the kernel core are "serial" (the serial port), "vga" (text output on VGA display), and "net" (raw UDP packets); in addition, the following klibs implements a console driver:
syslog: sends logs to a syslog server and/or to a local file (with file rotation capabilities)
gcp: sends logs to the Google Cloud logging server
The use of msg_err, msg_debug, msg_warn, etc. is just a way to deliver crude system messages directly to the console. We could use a logging facility that allows vectoring of messages between the console, a persistent log file, or a socket. It might not be a bad idea to figure out how these log entries might exist in a tuplified version, where things like time, debug level, subsystem, etc., are stored as attributes.
This will require some thinking through and discussion before coding.
The text was updated successfully, but these errors were encountered: